* Re: [PATCH] fec fix: Use OF 'ethernet' device as a provider of dma ops.
From: Grant Likely @ 2009-04-03 14:18 UTC (permalink / raw)
To: Grzegorz Bernacki; +Cc: linuxppc-dev
In-Reply-To: <12387682193290-git-send-email-gjb@semihalf.com>
This is already fixed in the netdev tree
g.
On Fri, Apr 3, 2009 at 8:16 AM, Grzegorz Bernacki <gjb@semihalf.com> wrote:
> Commit 4ae0ff6 "powerpc: expect all devices calling dma
> ops to have archdata set" assumes that all devices use
> correct dma ops. However FEC uses dma ops from 'eth'
> device which doesn't have proper archdata. This patch
> makes FEC use dma operation from OF 'ethernet' device,
> similarly to what other drivers (like gianfar) do.
>
> Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
> ---
> This is fix for not working FEC. Mounting root
> filesystem via NFS ends up with:
>
> Kernel BUG at c021b788 [verbose debug info unavailable]
> Oops: Exception in kernel mode, sig: 5 [#1]
> mpc5200-simple-platform
> Modules linked in:
> NIP: c021b788 LR: c021b758 CTR: 00000000
> REGS: c3825d40 TRAP: 0700 =A0 Not tainted =A0(2.6.29-07103-gd0b70e8)
> MSR: 00029032 <EE,ME,CE,IR,DR> =A0CR: 42008048 =A0XER: 20000000
> TASK =3D c3820000[1] 'swapper' THREAD: c3824000
> [...]
>
> =A0drivers/net/fec_mpc52xx.c | =A0 31 +++++++++++++++++++++----------
> =A01 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index cd8e98b..960b239 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -58,6 +58,8 @@ struct mpc52xx_fec_priv {
> =A0 =A0 =A0 =A0spinlock_t lock;
> =A0 =A0 =A0 =A0int msg_enable;
>
> + =A0 =A0 =A0 struct of_device *ofdev;
> +
> =A0 =A0 =A0 =A0/* MDIO link details */
> =A0 =A0 =A0 =A0int phy_addr;
> =A0 =A0 =A0 =A0unsigned int phy_speed;
> @@ -124,18 +126,23 @@ static int mpc52xx_fec_set_mac_address(struct net_d=
evice *dev, void *addr)
>
> =A0static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct=
bcom_task *s)
> =A0{
> + =A0 =A0 =A0 struct mpc52xx_fec_priv *priv =3D netdev_priv(dev);
> +
> =A0 =A0 =A0 =A0while (!bcom_queue_empty(s)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct bcom_fec_bd *bd;
> =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, (str=
uct bcom_bd **)&bd);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&dev->dev, bd->skb_pa, skb=
->len, DMA_FROM_DEVICE);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&priv->ofdev->dev, bd->skb=
_pa, skb->len,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DMA_FROM_DEVICE);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kfree_skb(skb);
> =A0 =A0 =A0 =A0}
> =A0}
>
> =A0static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct=
bcom_task *rxtsk)
> =A0{
> + =A0 =A0 =A0 struct mpc52xx_fec_priv *priv =3D netdev_priv(dev);
> +
> =A0 =A0 =A0 =A0while (!bcom_queue_full(rxtsk)) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct sk_buff *skb;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct bcom_fec_bd *bd;
> @@ -150,8 +157,8 @@ static int mpc52xx_fec_alloc_rx_buffers(struct net_de=
vice *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, sk=
b->data,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 FEC_RX_BUFF=
ER_SIZE, DMA_FROM_DEVICE);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&priv->ofdev-=
>dev, skb->data,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_submit_next_buffer(rxtsk, skb);
> =A0 =A0 =A0 =A0}
> @@ -388,7 +395,8 @@ static int mpc52xx_fec_hard_start_xmit(struct sk_buff=
*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_TX=
_BD_TC;
> - =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&dev->dev, skb->data, skb->le=
n, DMA_TO_DEVICE);
> + =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&priv->ofdev->dev, skb->data,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 skb->len, DMA_TO_DEVICE);
>
> =A0 =A0 =A0 =A0bcom_submit_next_buffer(priv->tx_dmatsk, skb);
>
> @@ -430,7 +438,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_dmat=
sk, NULL,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(struct bc=
om_bd **)&bd);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&dev->dev, bd->skb_pa, skb=
->len, DMA_TO_DEVICE);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&priv->ofdev->dev, bd->skb=
_pa, skb->len,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DMA_TO_DEVICE);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_kfree_skb_irq(skb);
> =A0 =A0 =A0 =A0}
> @@ -455,7 +464,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_dma=
tsk, &status,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(struct bc=
om_bd **)&bd);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&dev->dev, bd->skb_pa, rsk=
b->len, DMA_FROM_DEVICE);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(&priv->ofdev->dev, bd->skb=
_pa, rskb->len,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DMA_FROM_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,8 +474,9 @@ 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_prepa=
re_next_buffer(priv->rx_dmatsk);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bd->status =3D FEC_RX_BUFF=
ER_SIZE;
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_sing=
le(&dev->dev, rskb->data,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_sing=
le(&priv->ofdev->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 rskb->data, FEC_RX_BUFFER_SIZE,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 DMA_FROM_DEVICE);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_submit_next_buffer(pr=
iv->rx_dmatsk, rskb);
>
> @@ -499,7 +510,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(p=
riv->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, sk=
b->data,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bd->skb_pa =3D dma_map_single(&priv->ofdev-=
>dev, skb->data,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FEC_RX_BUF=
FER_SIZE, DMA_FROM_DEVICE);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0bcom_submit_next_buffer(priv->rx_dmatsk, s=
kb);
> @@ -910,7 +921,7 @@ mpc52xx_fec_probe(struct of_device *op, const struct =
of_device_id *match)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENOMEM;
>
> =A0 =A0 =A0 =A0priv =3D netdev_priv(ndev);
> -
> + =A0 =A0 =A0 priv->ofdev =3D op;
> =A0 =A0 =A0 =A0/* Reserve FEC control zone */
> =A0 =A0 =A0 =A0rv =3D of_address_to_resource(op->node, 0, &mem);
> =A0 =A0 =A0 =A0if (rv) {
> --
> 1.5.2.2
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] fec fix: Use OF 'ethernet' device as a provider of dma ops.
From: Grzegorz Bernacki @ 2009-04-03 14:16 UTC (permalink / raw)
To: linuxppc-dev
Commit 4ae0ff6 "powerpc: expect all devices calling dma
ops to have archdata set" assumes that all devices use
correct dma ops. However FEC uses dma ops from 'eth'
device which doesn't have proper archdata. This patch
makes FEC use dma operation from OF 'ethernet' device,
similarly to what other drivers (like gianfar) do.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
---
This is fix for not working FEC. Mounting root
filesystem via NFS ends up with:
Kernel BUG at c021b788 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
mpc5200-simple-platform
Modules linked in:
NIP: c021b788 LR: c021b758 CTR: 00000000
REGS: c3825d40 TRAP: 0700 Not tainted (2.6.29-07103-gd0b70e8)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 42008048 XER: 20000000
TASK = c3820000[1] 'swapper' THREAD: c3824000
[...]
drivers/net/fec_mpc52xx.c | 31 +++++++++++++++++++++----------
1 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cd8e98b..960b239 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -58,6 +58,8 @@ struct mpc52xx_fec_priv {
spinlock_t lock;
int msg_enable;
+ struct of_device *ofdev;
+
/* MDIO link details */
int phy_addr;
unsigned int phy_speed;
@@ -124,18 +126,23 @@ static int mpc52xx_fec_set_mac_address(struct net_device *dev, void *addr)
static void mpc52xx_fec_free_rx_buffers(struct net_device *dev, struct bcom_task *s)
{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
while (!bcom_queue_empty(s)) {
struct bcom_fec_bd *bd;
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(&priv->ofdev->dev, bd->skb_pa, skb->len,
+ DMA_FROM_DEVICE);
kfree_skb(skb);
}
}
static int mpc52xx_fec_alloc_rx_buffers(struct net_device *dev, struct bcom_task *rxtsk)
{
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+
while (!bcom_queue_full(rxtsk)) {
struct sk_buff *skb;
struct bcom_fec_bd *bd;
@@ -150,8 +157,8 @@ 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,
- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
+ bd->skb_pa = dma_map_single(&priv->ofdev->dev, skb->data,
+ FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(rxtsk, skb);
}
@@ -388,7 +395,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(&priv->ofdev->dev, skb->data,
+ skb->len, DMA_TO_DEVICE);
bcom_submit_next_buffer(priv->tx_dmatsk, skb);
@@ -430,7 +438,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(&priv->ofdev->dev, bd->skb_pa, skb->len,
+ DMA_TO_DEVICE);
dev_kfree_skb_irq(skb);
}
@@ -455,7 +464,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(&priv->ofdev->dev, bd->skb_pa, rskb->len,
+ DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
@@ -464,8 +474,9 @@ 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,
- FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
+ bd->skb_pa = dma_map_single(&priv->ofdev->dev,
+ rskb->data, FEC_RX_BUFFER_SIZE,
+ DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, rskb);
@@ -499,7 +510,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(&priv->ofdev->dev, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
@@ -910,7 +921,7 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
return -ENOMEM;
priv = netdev_priv(ndev);
-
+ priv->ofdev = op;
/* Reserve FEC control zone */
rv = of_address_to_resource(op->node, 0, &mem);
if (rv) {
--
1.5.2.2
^ permalink raw reply related
* Re: Interrupt ID number on mpc8347
From: Liu Dave-R63238 @ 2009-04-03 15:00 UTC (permalink / raw)
To: michael, yamazaki seiji; +Cc: linuxppc-dev
In-Reply-To: <1238756279.9595.15.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
> It's because the irqs are remapped by the kernel, the number in the
> device tree is a hardware irq number. The number you're printing out is
> a virtual irq number.
> of_irq_to_resource() is doing the remapping for you.
> You can turn on CONFIG_VIRQ_DEBUG and you'll get a file in debugfs that
> shows the mapping between hardware numbers and virtual numbers.
Guys,
I notice many people happened same issue to use the interrupt in powerpc
with DTS.
Could somebody write one documentation for interrupt system on powerpc arch,
- how to remap irq
- what is the virq? h/w irq.
- show the mapping virt->h/w..
etc..
I think if have this docs, it will be helpful.
Thanks, Dave
[-- Attachment #2: Type: text/html, Size: 1202 bytes --]
^ permalink raw reply
* RE: early kernel debugging
From: Tirumala Reddy Marri @ 2009-04-03 16:04 UTC (permalink / raw)
To: Yigal Goldberger, linuxppc-dev
In-Reply-To: <52907.72158.qm@web38901.mail.mud.yahoo.com>
I am not sure if I understand correctly. But Looks like you are not
passing the device tree along with kernel image and RAMDISK(you may not
need it if you are using NFS mount). You boot command should some what
look like this "bootm kernel_addr ramdisk_addr devtree_addr" or "bootm
kernel_addr - devtree_addr" . If you are already doing that I would
check my bootargs for correct params.
-----Original Message-----
From: linuxppc-dev-bounces+tmarri=3Damcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=3Damcc.com@ozlabs.org] On Behalf Of
Yigal Goldberger
Sent: Thursday, April 02, 2009 1:06 PM
To: linuxppc-dev@ozlabs.org
Subject: early kernel debugging
Hi All,
I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
I see that after uncompressing the kernel it hangs.
I found a location (System.map) I think corresponds to the __log_buf (my
SDRAM starts at physical address 0 (and u-boot performs -> Load Address:
00000000 Entry Point: 00000000) .
So I just removed the leading C0xxxxxx from the address leaving xxxxxx .
And that's where I looked .=20
I did see 2 error messages (though they were somewhat corrupt) the first
designated a memory fault and the second a kernel oops at some address.
I looked this address up on System.map and it's somewhere inside prom.c
in of_scan_flat_dt( ) .=20
I have a few question at this point :
A)Am I looking at the right memory location for __log_buf ?
B)What is printed to the buffer (printk's of what verbose level ?)
C)In a previous kernel version 2.6.14 I don't remember explicitly using
a flat device tree or pointing at such a tree through the bootm command)
, but I used the ARCH=3Dppc then as opposed to ARCH=3Dpowerpc Now .
I see a lot of stuff regarding the need to provide such a data structure
upon booting via bootm .Do I need to explicitly prepare such a data
structure and provide a pointer to it via bootm ?
Might this be the cause for this early hang ?
Best Regards,
Yigal Goldberger.=20
=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: early kernel debugging
From: Feng Kan @ 2009-04-03 16:47 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev, Yigal Goldberger
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C071F4F26@SDCEXCHANGE01.ad.amcc.com>
Hi:
Did you try the early kernel printk option in kernel hacking. It can
give some
very helpful information. Make sure the address for the physical uart
address is
passed in correctly.
Feng
Tirumala Reddy Marri wrote:
> I am not sure if I understand correctly. But Looks like you are not
> passing the device tree along with kernel image and RAMDISK(you may not
> need it if you are using NFS mount). You boot command should some what
> look like this "bootm kernel_addr ramdisk_addr devtree_addr" or "bootm
> kernel_addr - devtree_addr" . If you are already doing that I would
> check my bootargs for correct params.
>
> -----Original Message-----
> From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org] On Behalf Of
> Yigal Goldberger
> Sent: Thursday, April 02, 2009 1:06 PM
> To: linuxppc-dev@ozlabs.org
> Subject: early kernel debugging
>
>
> Hi All,
> I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
> I see that after uncompressing the kernel it hangs.
> I found a location (System.map) I think corresponds to the __log_buf (my
> SDRAM starts at physical address 0 (and u-boot performs -> Load Address:
> 00000000 Entry Point: 00000000) .
> So I just removed the leading C0xxxxxx from the address leaving xxxxxx .
> And that's where I looked .
> I did see 2 error messages (though they were somewhat corrupt) the first
> designated a memory fault and the second a kernel oops at some address.
> I looked this address up on System.map and it's somewhere inside prom.c
> in of_scan_flat_dt( ) .
>
> I have a few question at this point :
> A)Am I looking at the right memory location for __log_buf ?
> B)What is printed to the buffer (printk's of what verbose level ?)
> C)In a previous kernel version 2.6.14 I don't remember explicitly using
> a flat device tree or pointing at such a tree through the bootm command)
> , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now .
> I see a lot of stuff regarding the need to provide such a data structure
> upon booting via bootm .Do I need to explicitly prepare such a data
> structure and provide a pointer to it via bootm ?
> Might this be the cause for this early hang ?
>
> Best Regards,
> Yigal Goldberger.
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH] ps3vram: Replace mutex by spinlock + list
From: Jens Axboe @ 2009-04-03 18:03 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, linux-kernel, cbe-oss-dev
In-Reply-To: <1238763938-7076-4-git-send-email-Geert.Uytterhoeven@sonycom.com>
On Fri, Apr 03 2009, Geert Uytterhoeven wrote:
> Remove the mutex serializing access to the cache.
> Instead, queue up new requests on a list if the driver is busy.
>
> This improves sequential write performance by ca. 2%.
Great, precisely the method I wanted to see there! I've added your three
patches, thanks Geert.
--
Jens Axboe
^ permalink raw reply
* Re: Draft version of ML510 Linux patch (patch inlined)
From: Grant Likely @ 2009-04-03 20:33 UTC (permalink / raw)
To: Roderick Colenbrander; +Cc: linuxppc-dev
In-Reply-To: <1238613385.5034.15.camel@roderick64>
On Wed, Apr 1, 2009 at 1:16 PM, Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
> Hi,
>
> As requested by Grant Likely here the same patch but now inlined.
word wrapped. neener neener.
Mostly looks good to me. It would help to split the PCI driver out
into a separate patch from the board support. Comments below.
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
> ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
> --- linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
> +++ ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
A bunch of oddities in this .dts file; but that's not your fault. The
xilinx device tree generator needs some TLC.
> +/dts-v1/;
> +/ {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + compatible =3D "xlnx,ml510-ref-design";
I still haven't decided how best to handle the board level compatible
value for the Virtex, but this will do for now.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 plbv46_pci_0: plbv46-pci@85e00000 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <3>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "xlnx,plbv46=
-pci-1.03.a";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "pci";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D < 0x85e00000 0x1000=
0 >; /* addr is at +0x10c, data at +0x110
> */
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* The PCI bus is implement=
ed by a soft-core which is connected to
> the PLB bus which is seen by the CPU at 0xa0000000.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Both the PLB and PCI h=
ave their own address domain. The PCI
> soft-core performs this translation. The Xilinx plbpci doc
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* mentions 'the number o=
f high-order bits substituted in the PLB
> address presented to the bridge is given by the number
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* of bits that are the S=
AME between C_IPIFBAR_N and
> C_IPIF_HIGHADDR_N.'
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* For the default ml510_=
bsb1_pcores_ppc440 reference design this
> means:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* C_IPIFBAR_0 =A0 =A0 =
=A0 =A0=3D 0xa0000000
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* C_IPIF_HIGHADDR_0 =A0=
=3D 0xbfffffff <- only the last 3 bits of
> (0xa=3D1010b, 0xb=3D1011b) are similar
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* C_IPIFBAR2PCIBAR_0 =3D=
0x00000000
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* C_IPIFBAR_1 =A0 =A0 =
=A0 =A0=3D 0x94000000
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* C_IPIF_HIGHADDR_1 =A0=
=3D 0x97ffffff <- only the last 6 bits are
> similar
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* C_IPIFBAR2PCIBAR_1 =3D=
0x00000000
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* This means that a CPU =
write to 0xa0001234 translates to
> 0x00001234 on the PCI bus and that
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* the pcibar_0 base and =
pcibar_1 base are zero. In order to prevent
> collision between inbound
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* and outbound memory re=
ads/writes C_IPIFBAR2PCIBAR_0 needs to be
> set to 0x80000000.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
Line lengths, especially in comment blocks, should be restricted to 80
characters.
This description really belongs in the device tree binding
documentation in Documentation/powerpc/dts-bindings because it is not
ml510 specific.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ranges =3D <0x02000000 0x00=
000000 0x80000000 0xa0000000 0x00000000
> 0x20000000
I think we've been over this before, but why do the PLB and PCI
addresses differ here? For mem regions I:q
t is legal for them to be different, but things are simpler if they match.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x01000=
000 0x00000000 0x00000000 0x94000000 0x00000000
> 0x00010000>;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-cells =3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-parent =3D <&xps_=
intc_0>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-map-mask =3D <0xf=
f00 0x0 0x0 0x7>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-map =3D <
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x=
15 / dev=3D5, bus=3D0 / PCI slot 5 */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* pci irq =
a is connected to xintc irq 5, b to 4, c to 3 and d to 2
> */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Accordin=
g to the datasheet + schematic ABCD [FPGA] of slot 5 is
> mapped to DABC, testing showed that at least A maps to B */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x2800 0 0 =
1 &xps_intc_0 4 2
> +// =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x2800 0 0 2 =
&xps_intc_0 5 2
> +// =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x2800 0 0 3 =
&xps_intc_0 4 2
> +// =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x2800 0 0 4 =
&xps_intc_0 3 2
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x=
16 / dev=3D6, bus=3D0 / PCI slot 3 */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x3000 0 0 =
1 &xps_intc_0 3 2
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x3000 0 0 =
2 &xps_intc_0 2 2
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x3000 0 0 =
3 &xps_intc_0 5 2
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x3000 0 0 =
4 &xps_intc_0 4 2
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x=
11 / dev=3D1, bus=3D0 / AC97 audio */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x0800 0 0 =
1 &i8259 7 2
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x=
1b / dev=3D11, bus=3D0 / IDE */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x5800 0 0 =
1 &i8259 14 2
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* IDSEL 0x=
1f / dev 15, bus=3D0 / USB */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x7800 0 0 =
1 &i8259 7 2
What about the other ALI devices? May as well fill those in too.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 >;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ali_m1533 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells=
=3D <1>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-ce=
lls =3D <2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i8259: inte=
rrupt-controller@20 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 reg =3D <1 0x20 2
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 0xa0 2
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 0x4d0 2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 interrupt-controller;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 device_type =3D "interrupt-controller";
You should be able to drop device_type here
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 #address-cells =3D <0>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 #interrupt-cells =3D <2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 compatible =3D "chrp,iic";
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 interrupts =3D <1 2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 interrupt-parent =3D <&xps_intc_0>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } ;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffff=
0000 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "xlnx,xps-br=
am-if-cntlr-1.00.a";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D < 0xffff0000 0x1000=
0 >;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xlnx,family =3D "virtex5";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } ;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 xps_intc_0: interrupt-controller@81800000 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #interrupt-cells =3D <0x2>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "xlnx,xps-in=
tc-1.00.a";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interrupt-controller ;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D < 0x81800000 0x1000=
0 >;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 xlnx,num-intr-inputs =3D <0=
xc>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } ;
> + =A0 =A0 =A0 } ;
> +} =A0;
> linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig
> ml510-dev/linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig
> --- linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig =A0 =A0 2009-=
03-24
> 00:12:14.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig
Put the defconfig changes into a separate patch.
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/platforms/44x/Kconfig
> ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Kconfig
> --- linux-2.6.29/arch/powerpc/platforms/44x/Kconfig =A0 =A0 2009-03-24
> 00:12:14.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Kconfig =A0 2009-03=
-27
> 15:50:28.000000000 +0100
> @@ -160,6 +160,16 @@
> =A0 =A0 =A0 =A0 =A0Most Virtex 5 designs should use this unless it needs =
to do some
> =A0 =A0 =A0 =A0 =A0special configuration at board probe time.
>
> +config XILINX_ML510
> + =A0 =A0 =A0 bool "Xilinx ML510 Reference Design support"
> + =A0 =A0 =A0 depends on 44x
> + =A0 =A0 =A0 default n
> + =A0 =A0 =A0 select XILINX_VIRTEX_5_FXT
> + =A0 =A0 =A0 select PPC_PCI_CHOICE
> + =A0 =A0 =A0 select XILINX_VIRTEX_PCI if PCI
> + =A0 =A0 =A0 select PPC_INDIRECT_PCI if PCI
> + =A0 =A0 =A0 select PPC_I8259 if PCI
> +
> =A0config PPC44x_SIMPLE
> =A0 =A0 =A0 =A0bool "Simple PowerPC 44x board support"
> =A0 =A0 =A0 =A0depends on 44x
> @@ -232,4 +242,3 @@
> =A0config XILINX_VIRTEX_5_FXT
> =A0 =A0 =A0 =A0bool
> =A0 =A0 =A0 =A0select XILINX_VIRTEX
> -
^^^^^^^^^^^^^^^^^^^^^^
unrelated whitespace change
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/platforms/44x/Makefile
> ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Makefile
> --- linux-2.6.29/arch/powerpc/platforms/44x/Makefile =A0 =A02009-03-24
> 00:12:14.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Makefile
> 2009-04-01 11:59:28.000000000 +0200
> @@ -4,3 +4,4 @@
> =A0obj-$(CONFIG_SAM440EP) =A0 =A0 =A0 =A0 +=3D sam440ep.o
> =A0obj-$(CONFIG_WARP) =A0 =A0 +=3D warp.o
> =A0obj-$(CONFIG_XILINX_VIRTEX_5_FXT) +=3D virtex.o
> +obj-$(CONFIG_XILINX_ML510) +=3D ml510.o
> \ No newline at end of file
^^^^^^^^^^^^^^^^^^^^^^^
Fix this.
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/platforms/44x/ml510.c
> ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/ml510.c
> --- linux-2.6.29/arch/powerpc/platforms/44x/ml510.c =A0 =A0 1970-01-01
> 01:00:00.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/ml510.c =A0 2009-04=
-01
> 12:42:28.000000000 +0200
> @@ -0,0 +1,161 @@
> +/*
> + * Xilinx ML510 Reference Design support, derived from
> + * the generic Xilinx Virtex 5 board support
> + *
> + * Copyright 2007 Secret Lab Technologies Ltd.
> + * Copyright 2008 Xilinx, Inc.
> + * Copyright 2009 Roderick Colenbrander
> + *
> + * The i8259 cascade code was derived from 86xx/pic.c which is
> copyrighted by Freescale Semiconductor, Inc.
> + * Xilinx ML510 PCI initialization code, derived from the Xilinx
> ML300/ML410 based board support.
Keep line lengths under 80 characters.
> + *
> + * This file is licensed under the terms of the GNU General Public
> License
> + * version 2. This program is licensed "as is" without any warranty of
> any
> + * kind, whether express or implied.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/time.h>
> +#include <asm/xilinx_intc.h>
> +#include <asm/reg.h>
> +#include <asm/ppc4xx.h>
> +#ifdef CONFIG_PPC_I8259
> +#include <asm/i8259.h>
> +#endif
> +#ifdef CONFIG_PCI
> +#include <linux/pci.h>
> +#endif
> +#include "44x.h"
> +
> +static struct of_device_id xilinx_of_bus_ids[] __initdata =3D {
> + =A0 =A0 =A0 { .compatible =3D "simple-bus", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,plb-v46-1.00.a", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,plb-v46-1.02.a", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,plb-v34-1.01.a", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,plb-v34-1.02.a", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,opb-v20-1.10.c", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,dcr-v29-1.00.a", },
> + =A0 =A0 =A0 { .compatible =3D "xlnx,compound", },
> + =A0 =A0 =A0 {}
> +};
> +
> +#ifdef CONFIG_PPC_I8259
> +static void ml510_8259_cascade(unsigned int irq, struct irq_desc *desc)
> +{
> + =A0 =A0 =A0 unsigned int cascade_irq =3D i8259_irq();
> + =A0 =A0 =A0 if (cascade_irq !=3D NO_IRQ)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 generic_handle_irq(cascade_irq);
> +
> + =A0 =A0 =A0 /* Let xilinx_intc end the interrupt */
> + =A0 =A0 =A0 desc->chip->ack(irq);
> + =A0 =A0 =A0 desc->chip->unmask(irq);
> +}
> +
> +static void __init ml510_setup_i8259_cascade(void)
> +{
> + =A0 =A0 =A0 struct device_node *np, *cascade_node =3D NULL;
> + =A0 =A0 =A0 int cascade_irq;
> +
> + =A0 =A0 =A0 /* Initialize i8259 controller */
> + =A0 =A0 =A0 for_each_node_by_type(np, "interrupt-controller")
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (of_device_is_compatible=
(np, "chrp,iic")) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 cascade_node =3D np;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 break;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 if (cascade_node =3D=3D NULL) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_DEBUG "Could no=
t find i8259 PIC\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 cascade_irq =3D irq_of_parse_and_map(cascade_node, 0);
> + =A0 =A0 =A0 if (cascade_irq =3D=3D NO_IRQ) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "Failed to =
map cascade interrupt\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 i8259_init(cascade_node, 0);
> +
> + =A0 =A0 =A0 of_node_put(cascade_node);
> + =A0 =A0 =A0 set_irq_chained_handler(cascade_irq, ml510_8259_cascade);
> +}
> +#endif /* CONFIG_PPC_I8259 */
> +
> +#ifdef CONFIG_PCI
> +static void __devinit ali_quirk(struct pci_dev *dev)
> +{
> + =A0 =A0 =A0 /* Enable the IDE controller */
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x58, 0x4c);
> + =A0 =A0 =A0 /* Assign irq 14 to the primary ide channel */
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x44, 0x0d);
> + =A0 =A0 =A0 /* Assign irq 15 to the secondary ide channel */
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x75, 0x0f);
> + =A0 =A0 =A0 /* Set the ide controller in native mode */
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x09, 0xff);
> +
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x48, 0x00); // INTB =3D disable=
d, INTA =3D
> disabled
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x4a, 0x00); // INTD =3D disable=
d, INTC =3D
> disabled
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x4b, 0x00); // Audio =3D INT7, =
Modem =3D
> disabled.
> + =A0 =A0 =A0 pci_write_config_byte(dev, 0x74, 0x06); // USB =3D INT7
> +}
> +DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ali_quirk);
> +#endif /* CONFIG_PCI */
> +
> +static int __init ml510_device_probe(void)
> +{
> + =A0 =A0 =A0 of_platform_bus_probe(NULL, xilinx_of_bus_ids, NULL);
> +
> + =A0 =A0 =A0 return 0;
> +}
> +machine_device_initcall(ml510, ml510_device_probe);
> +
> +static int __init ml510_probe(void)
> +{
> + =A0 =A0 =A0 unsigned long root =3D of_get_flat_dt_root();
> +
> + =A0 =A0 =A0 if (!of_flat_dt_is_compatible(root, "xlnx,ml510-ref-design"=
))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
> +
> + =A0 =A0 =A0 return 1;
or just: return of_flat_dt_is_compatible(root, "xlnx,ml510-ref-design");
> +}
> +
> +void virtex_pci_init(void);
> +static void __init ml510_setup_arch(void)
> +{
> + =A0 =A0 =A0 struct device_node *pci_node =3D of_find_compatible_node(NU=
LL, NULL,
> "xlnx,plbv46-pci-1.03.a");
> +
> +#ifdef CONFIG_PCI
> + =A0 =A0 =A0 if(pci_node)
> + =A0 =A0 =A0 {
> +//Is this the right way or should this be done using OF?
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Register the host bridge */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtex_pci_init();
> + =A0 =A0 =A0 }
No, you don't need to use of_platform bus here. Doing it with
discrete reads of the device tree is fine. However, you should move
the of_find_compatible_node() call into virtex_pci_init() itself.
Oh, and don't use '//' style comments.
> +#endif /* CONFIG_PCI */
> +}
> +
> +static void ml510_init_IRQ(void)
> +{
> + =A0 =A0 =A0 xilinx_intc_init_tree();
> +
> +#ifdef CONFIG_PPC_I8259
> + =A0 =A0 =A0 /* The devices on the ALI M1553 south bridge are connected =
to an
> internal i8259 */
> + =A0 =A0 =A0 ml510_setup_i8259_cascade();
> + =A0 =A0 =A0 /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitiv=
e */
> + =A0 =A0 =A0 outb(0xc0, 0x4d0);
> + =A0 =A0 =A0 outb(0xc0, 0x4d1);
> +#endif /* CONFIG_PPC_I8259 */
> +}
> +
> +define_machine(ml510) {
> + =A0 =A0 =A0 .name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D "Xilinx ML510=
Reference Design support",
> + =A0 =A0 =A0 .probe =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D ml510_probe,
> + =A0 =A0 =A0 .setup_arch =A0 =A0 =A0 =A0 =A0 =A0 =3D ml510_setup_arch,
> + =A0 =A0 =A0 .init_IRQ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D ml510_init_IRQ,
> + =A0 =A0 =A0 .get_irq =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D xilinx_intc_get=
_irq,
> + =A0 =A0 =A0 .calibrate_decr =A0 =A0 =A0 =A0 =3D generic_calibrate_decr,
> + =A0 =A0 =A0 .restart =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D ppc4xx_reset_sy=
stem,
> +};
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/sysdev/Kconfig
> ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Kconfig
> --- linux-2.6.29/arch/powerpc/sysdev/Kconfig =A0 =A02009-03-24
> 00:12:14.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Kconfig =A02009-03-27
> 12:50:29.000000000 +0100
> @@ -12,3 +12,7 @@
> =A0 =A0 =A0 =A0depends on PCI_MSI
> =A0 =A0 =A0 =A0default y if MPIC
> =A0 =A0 =A0 =A0default y if FSL_PCI
> +
> +config XILINX_VIRTEX_PCI
> + =A0 =A0 =A0 bool
> + =A0 =A0 =A0 depends on PCI
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/sysdev/Makefile
> ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Makefile
> --- linux-2.6.29/arch/powerpc/sysdev/Makefile =A0 2009-03-24
> 00:12:14.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Makefile 2009-03-27
> 11:57:45.000000000 +0100
> @@ -34,6 +34,7 @@
> =A0obj-$(CONFIG_4xx) =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D uic.o
> =A0obj-$(CONFIG_4xx_SOC) =A0 =A0 =A0 =A0 =A0+=3D ppc4xx_soc.o
> =A0obj-$(CONFIG_XILINX_VIRTEX) =A0 =A0+=3D xilinx_intc.o
> +obj-$(CONFIG_XILINX_VIRTEX_PCI) =A0 =A0 =A0 =A0+=3D virtex_pci.o
> =A0obj-$(CONFIG_OF_RTC) =A0 =A0 =A0 =A0 =A0 +=3D of_rtc.o
> =A0ifeq ($(CONFIG_PCI),y)
> =A0obj-$(CONFIG_4xx) =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D ppc4xx_pci.o
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c
> ml510-dev/linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c
> --- linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c =A0 =A0 =A0 1970-01-01
> 01:00:00.000000000 +0100
> +++ ml510-dev/linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c =A0 =A0 2009-=
04-01
> 12:54:42.000000000 +0200
> @@ -0,0 +1,95 @@
> +/*
> + * PCI support for Xilinx plbv46_pci soft-core which can be used on
> Xilinx Virtex ML410 / ML510 boards.
> + *
> + * Copyright 2009 Roderick Colenbrander
> + *
> + * The pci bridge fixup code was copied from ppc4xx_pci.c and was
> written by Benjamin Herrenschmidt.
> + * Copyright 2007 Ben. Herrenschmidt <benh@kernel.crashing.org>, IBM
> Corp.
> + *
> + * This file is licensed under the terms of the GNU General Public
> License
> + * version 2. This program is licensed "as is" without any warranty of
> any
> + * kind, whether express or implied.
> + */
> +
> +#include <linux/pci.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/io.h>
> +
> +#define XPLB_PCI_ADDR 0x10c
> +#define XPLB_PCI_DATA 0x110
> +#define XPLB_PCI_BUS =A00x114
> +
> +#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY |
> PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
> +
> +static void fixup_virtex_pci_bridge(struct pci_dev *dev)
> +{
> + =A0 =A0 =A0 struct pci_controller *hose;
> + =A0 =A0 =A0 int i;
> +
> + =A0 =A0 =A0 if (dev->devfn !=3D 0 || dev->bus->self !=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
Could simply be: if (dev->devfn || dev->bus->self)
> +
> + =A0 =A0 =A0 hose =3D pci_bus_to_host(dev->bus);
> + =A0 =A0 =A0 if (hose =3D=3D NULL)
if (!hose)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> +
> + =A0 =A0 =A0 if(!of_device_is_compatible(hose->dn, "xlnx,plbv46-pci-1.03=
.a"))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> +
> + =A0 =A0 =A0 /* Hide the PCI host BARs from the kernel as their content =
doesn't
> + =A0 =A0 =A0 =A0* fit well in the resource management
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 for (i =3D 0; i < DEVICE_COUNT_RESOURCE; i++) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev->resource[i].start =3D dev->resource[i]=
.end =3D 0;
Chaining up start =3D end =3D 0 like this is discouraged. Use one
assignment per line.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev->resource[i].flags =3D 0;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 printk(KERN_INFO "PCI: Hiding Xilinx plb-pci host bridge re=
sources %s
> \n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0pci_name(dev));
replace printk(KERN_INFO "..."); with dev_info();
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID,
> fixup_virtex_pci_bridge);
> +
> +void virtex_pci_init(void)
> +{
> + =A0 =A0 =A0 struct device_node *pci_node =3D of_find_compatible_node(NU=
LL, NULL,
> "xlnx,plbv46-pci-1.03.a");
> +
> + =A0 =A0 =A0 if(pci_node)
> + =A0 =A0 =A0 {
if (!pci_node)
return;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct pci_controller *hose;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct resource r;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 void __iomem *pci_reg;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("Found a Xilinx plb-pci host bridge\=
n");
ditto here
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(of_address_to_resource(pci_node, 0, &r))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("No address for Xili=
nx plb-pci host bridge\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 hose =3D pcibios_alloc_controller(pci_node)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!hose)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 hose->first_busno =3D 0;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 hose->last_busno =3D 1; /* there are two sl=
ots behind a TI2250
> pci-to-pci bridge */
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Setup config space */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 setup_indirect_pci(hose, r.start + XPLB_PCI=
_ADDR, r.start +
> XPLB_PCI_DATA, 0);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* According to the xilinx plbv46_pci docum=
entation the soft-core
> starts a self-init when the bus master enable bit is set.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Without this bit set the pci bus can't=
be scanned. */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 early_write_config_word(hose, 0, 0, PCI_COM=
MAND,
> PCI_HOST_ENABLE_CMD);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Set the max latency timer to 255 */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 early_write_config_byte(hose, 0, 0, PCI_LAT=
ENCY_TIMER, 0xff);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Set the max bus number to 255 */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pci_reg =3D of_iomap(pci_node, 0);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_8(pci_reg + XPLB_PCI_BUS, 0xff);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iounmap(pci_reg);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Register the host bridge with the linux =
kernel! */
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pci_process_bridge_OF_ranges(hose, pci_node=
, 1 /* primary=3Dyes */);
Drop the comment in the parameters. Readers will go and look at the
declaration of pci_process_bridge_OF_ranges()
> + =A0 =A0 =A0 }
> +}
> diff -urN -X linux-2.6.29/Documentation/dontdiff
> linux-2.6.29/drivers/ide/alim15x3.c
> ml510-dev/linux-2.6.29/drivers/ide/alim15x3.c
> --- linux-2.6.29/drivers/ide/alim15x3.c 2009-03-24 00:12:14.000000000
> +0100
> +++ ml510-dev/linux-2.6.29/drivers/ide/alim15x3.c =A0 =A0 =A0 2009-03-27
> 14:47:50.000000000 +0100
> @@ -401,7 +401,8 @@
> =A0 =A0 =A0 =A0return cbl;
> =A0}
>
> -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
> +#if !defined(CONFIG_SPARC64)
> +// && !defined(CONFIG_PPC)
heh, I think you know what you need to do here.
> =A0/**
> =A0* =A0 =A0 init_hwif_ali15x3 =A0 =A0 =A0 - =A0 =A0 =A0 Initialize the A=
LI IDE x86 stuff
> =A0* =A0 =A0 @hwif: interface to configure
>
>
> _______________________________________________
> 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: GDB problem with Xilinx GIT Linux on Virtex5FX PPC440
From: Grant Likely @ 2009-04-03 20:35 UTC (permalink / raw)
To: Frederic LEGER; +Cc: linuxppc-dev
In-Reply-To: <000701c99cef$c27da220$3e0414ac@esisar.inpg.fr>
I unfortunately don't have an answer for you, but I have had problems
in the past with GDB on virtex ppc405. I don't know if it is related.
I'll try to dig up my old notes, but no promises.
g.
On Wed, Mar 4, 2009 at 11:36 AM, Frederic LEGER
<frederic.leger@esisar.grenoble-inp.fr> wrote:
> Hi,
>
> At the moment I can't set any breakpoint under gdb or gdbserver on ML510 and
> AVNETV5FX30T, if I set one => die "continuing...".
>
> Everything else is OK for a while on both boards: cross-compiling, dhcp,
> netperf, custom apps, .... but not debugging !
>
> If you have a working gdb (and/or gdbserver) on PPC440 Linux , could you
> please anwer this message with the following piece of information:
>
> Board
> kernel revision
> kernel snapshot (day/number) used from Xilinx GIT
> defconfig used
> toolchain (ELDK/buildroot...)
> toolchain version
> location of the rootfs (ramdisk, SysACE partition, flash Uboot partition)
> Type of the rootfs
>
> Thank you very much in advance.
>
> Best regards,
>
> Frederic
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] cpm_uart: Initialize port.dev before it's used.
From: Scott Wood @ 2009-04-03 20:48 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Previously, this caused NULL to sometimes be passed as a device
to the DMA code. With recent DMA changes, that now causes a BUG().
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
This is a regression triggered by DMA changes; please apply for 2.6.30.
drivers/serial/cpm_uart/cpm_uart_core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 5c6ef51..4dd00be 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1339,13 +1339,13 @@ static int __devinit cpm_uart_probe(struct of_device *ofdev,
dev_set_drvdata(&ofdev->dev, pinfo);
+ /* initialize the device pointer for the port */
+ pinfo->port.dev = &ofdev->dev;
+
ret = cpm_uart_init_port(ofdev->node, pinfo);
if (ret)
return ret;
- /* initialize the device pointer for the port */
- pinfo->port.dev = &ofdev->dev;
-
return uart_add_one_port(&cpm_reg, &pinfo->port);
}
--
1.5.6.rc1.6.gc53ad.dirty
^ permalink raw reply related
* [PATCH] pq2fads: Update device tree for use with device-tree-aware u-boot.
From: Scott Wood @ 2009-04-03 20:58 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Add aliases, and correct CS0 offset to match how u-boot
programs it (this was not a problem with cuImage because
the wrapper would reprogram the localbus to match the device
tree).
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/dts/pq2fads.dts | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/pq2fads.dts b/arch/powerpc/boot/dts/pq2fads.dts
index b2d6109..0bb6693 100644
--- a/arch/powerpc/boot/dts/pq2fads.dts
+++ b/arch/powerpc/boot/dts/pq2fads.dts
@@ -17,6 +17,14 @@
#address-cells = <1>;
#size-cells = <1>;
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -45,7 +53,7 @@
#size-cells = <1>;
reg = <0xf0010100 0x60>;
- ranges = <0x0 0x0 0xfe000000 0x800000
+ ranges = <0x0 0x0 0xff800000 0x800000
0x1 0x0 0xf4500000 0x8000
0x8 0x0 0xf8200000 0x8000>;
@@ -71,7 +79,7 @@
};
};
- pci@f0010800 {
+ pci0: pci@f0010800 {
device_type = "pci";
reg = <0xf0010800 0x10c 0xf00101ac 0x8 0xf00101c4 0x8>;
compatible = "fsl,mpc8280-pci", "fsl,pq2-pci";
@@ -142,7 +150,7 @@
reg = <0x119f0 0x10 0x115f0 0x10>;
};
- serial@11a00 {
+ serial0: serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
@@ -153,7 +161,7 @@
fsl,cpm-command = <0x800000>;
};
- serial@11a20 {
+ serial1: serial@11a20 {
device_type = "serial";
compatible = "fsl,mpc8280-scc-uart",
"fsl,cpm2-scc-uart";
@@ -164,7 +172,7 @@
fsl,cpm-command = <0x4a00000>;
};
- ethernet@11320 {
+ enet0: ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
@@ -176,7 +184,7 @@
fsl,cpm-command = <0x16200300>;
};
- ethernet@11340 {
+ enet1: ethernet@11340 {
device_type = "network";
compatible = "fsl,mpc8280-fcc-enet",
"fsl,cpm2-fcc-enet";
--
1.5.6.rc1.6.gc53ad.dirty
^ permalink raw reply related
* [PATCH] cpm_uart: Disable CPM udbg when re-initing CPM uart, even if not the console.
From: Scott Wood @ 2009-04-03 21:15 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Previously, if udbg was using the CPM uart, and the normal CPM uart driver
was enabled, but the console was directed elsewhere, udbg would not be
stopped prior to initialization. This resulted in udbg hanging forever
waiting for the CPM to process a descriptor.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 4dd00be..f8df068 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1106,6 +1106,10 @@ static int cpm_uart_init_port(struct device_node *np,
for (i = 0; i < NUM_GPIOS; i++)
pinfo->gpios[i] = of_get_gpio(np, i);
+#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
+ udbg_putc = NULL;
+#endif
+
return cpm_uart_request_port(&pinfo->port);
out_pram:
@@ -1255,10 +1259,6 @@ static int __init cpm_uart_console_setup(struct console *co, char *options)
baud = 9600;
}
-#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
- udbg_putc = NULL;
-#endif
-
if (IS_SMC(pinfo)) {
out_be16(&pinfo->smcup->smc_brkcr, 0);
cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
--
1.5.6.rc1.6.gc53ad.dirty
^ permalink raw reply related
* [PATCH] Powerpc: Xilinx: Intc: Fix level irqs which have duplicates
From: John Linn @ 2009-04-03 22:55 UTC (permalink / raw)
To: grant.likely, linuxppc-dev, jwboyer; +Cc: John Linn
The interrupt controller was not handling level interrupts correctly
such that duplicate interrupts were happening. This fixes the problem
and adds edge type interrupts which are needed in Xilinx hardware.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
arch/powerpc/sysdev/xilinx_intc.c | 112 ++++++++++++++++++++++++++++++++++---
1 files changed, 103 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
index a22e1a2..7c99a1e 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -41,8 +41,30 @@
static struct irq_host *master_irqhost;
+/* The following table allows the interrupt type, edge or level,
+ * to be cached after being read from the device tree until the interrupt
+ * is mapped
+ */
+static int xilinx_intc_typetable[32];
+
+/* Map the interrupt type from the device tree to the interrupt types
+ * used by the interrupt subsystem
+ */
+static unsigned char xilinx_intc_map_senses[] = {
+ IRQ_TYPE_EDGE_RISING,
+ IRQ_TYPE_EDGE_FALLING,
+ IRQ_TYPE_LEVEL_HIGH,
+ IRQ_TYPE_LEVEL_LOW,
+};
+
/*
- * IRQ Chip operations
+ * The interrupt controller is setup such that it doesn't work well with
+ * the level interrupt handler in the kernel because the handler acks the
+ * interrupt before calling the application interrupt handler. To deal with
+ * that, we use 2 different irq chips so that different functions can be
+ * used for level and edge type interrupts.
+ *
+ * IRQ Chip common (across level and edge) operations
*/
static void xilinx_intc_mask(unsigned int virq)
{
@@ -52,15 +74,54 @@ static void xilinx_intc_mask(unsigned int virq)
out_be32(regs + XINTC_CIE, 1 << irq);
}
-static void xilinx_intc_unmask(unsigned int virq)
+static int xilinx_intc_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct irq_desc *desc = get_irq_desc(virq);
+
+ desc->status &= ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
+ desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
+ if (flow_type & (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
+ desc->status |= IRQ_LEVEL;
+ return 0;
+}
+
+/*
+ * IRQ Chip level operations
+ */
+static void xilinx_intc_level_unmask(unsigned int virq)
{
int irq = virq_to_hw(virq);
void * regs = get_irq_chip_data(virq);
pr_debug("unmask: %d\n", irq);
out_be32(regs + XINTC_SIE, 1 << irq);
+
+ /* ack level irqs because they can't be acked during
+ * ack function since the handle_level_irq function
+ * acks the irq before calling the inerrupt handler
+ */
+ out_be32(regs + XINTC_IAR, 1 << irq);
+}
+
+static struct irq_chip xilinx_intc_level_irqchip = {
+ .typename = "Xilinx Level INTC",
+ .mask = xilinx_intc_mask,
+ .mask_ack = xilinx_intc_mask,
+ .unmask = xilinx_intc_level_unmask,
+ .set_type = xilinx_intc_set_type,
+};
+
+/*
+ * IRQ Chip edge operations
+ */
+static void xilinx_intc_edge_unmask(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void *regs = get_irq_chip_data(virq);
+ pr_debug("unmask: %d\n", irq);
+ out_be32(regs + XINTC_SIE, 1 << irq);
}
-static void xilinx_intc_ack(unsigned int virq)
+static void xilinx_intc_edge_ack(unsigned int virq)
{
int irq = virq_to_hw(virq);
void * regs = get_irq_chip_data(virq);
@@ -68,27 +129,60 @@ static void xilinx_intc_ack(unsigned int virq)
out_be32(regs + XINTC_IAR, 1 << irq);
}
-static struct irq_chip xilinx_intc_irqchip = {
- .typename = "Xilinx INTC",
+static struct irq_chip xilinx_intc_edge_irqchip = {
+ .typename = "Xilinx Edge INTC",
.mask = xilinx_intc_mask,
- .unmask = xilinx_intc_unmask,
- .ack = xilinx_intc_ack,
+ .unmask = xilinx_intc_edge_unmask,
+ .ack = xilinx_intc_edge_ack,
+ .set_type = xilinx_intc_set_type,
};
/*
* IRQ Host operations
*/
+
+/**
+ * xilinx_intc_xlate - translate virq# from device tree interrupts property
+ */
+static int xilinx_intc_xlate(struct irq_host *h, struct device_node *ct,
+ u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_flags)
+{
+ if (intsize != 2)
+ return -1;
+
+ /* keep a copy of the interrupt type til the interrupt is mapped
+ */
+ xilinx_intc_typetable[intspec[0]] = xilinx_intc_map_senses[intspec[1]];
+
+ /* Xilinx uses 2 interrupt entries, the 1st being the h/w
+ * interrupt number, the 2nd being the interrupt type, edge or level
+ */
+ *out_hwirq = intspec[0];
+ *out_flags = xilinx_intc_map_senses[intspec[1]];
+
+ return 0;
+}
static int xilinx_intc_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t irq)
{
set_irq_chip_data(virq, h->host_data);
- set_irq_chip_and_handler(virq, &xilinx_intc_irqchip, handle_level_irq);
- set_irq_type(virq, IRQ_TYPE_NONE);
+
+ if (xilinx_intc_typetable[irq] == IRQ_TYPE_LEVEL_HIGH ||
+ xilinx_intc_typetable[irq] == IRQ_TYPE_LEVEL_LOW) {
+ set_irq_chip_and_handler(virq, &xilinx_intc_level_irqchip,
+ handle_level_irq);
+ } else {
+ set_irq_chip_and_handler(virq, &xilinx_intc_edge_irqchip,
+ handle_edge_irq);
+ }
return 0;
}
static struct irq_host_ops xilinx_intc_ops = {
.map = xilinx_intc_map,
+ .xlate = xilinx_intc_xlate,
};
struct irq_host * __init
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH] powerpc: Keep track of emulated instructions
From: Michael Ellerman @ 2009-04-04 4:37 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <alpine.LRH.2.00.0904031404450.32353@vixen.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
On Fri, 2009-04-03 at 14:08 +0200, Geert Uytterhoeven wrote:
> Hi Ben, Kumar,
>
> Finally (after ca. 1.5 years), he're an updated version of my patch to keep
> track of emulated instructions. In the light of Kumar's `Emulate enough of SPE
> instructions to make gcc happy' patch, he probably also wants to keep track of
> the actual runtime overhead.
>
> Changes since last version:
> - arch/powerpc/kernel/sysfs.c is now compiled on ppc32, so we can provide
> counters in sysfs on ppc32, too,
> - WARN_EMULATED() is a no-op if CONFIG_SYSCTL is disabled,
> - Add warnings for altivec,
> - Add warnings for recently introduced emulation of vsx and isel
> instructions.
You don't count instructions that fall through to the bottom of
fix_alignment()?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* CONFIG_PREEMPT and High Resolution Timers problem
From: Vijay Nikam @ 2009-04-04 12:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood
Hello All,
I have mpc8313erdb eval board with Linux-2.6.20 running on it.
Recently I had a problem, I wrote a driver and from I am sending
notification to user space application using fasync driver method
(SIGIO signal). In user space applicaion process I have used
posix-timers (timer_create and timer_settime), the timer is set for
10ms. But in actual I checked on oscilloscope the expiration of timer
or signal event generation varies between 10ms - 13ms. In kerenl
driver when the interrupt occurs I am making a gpio pin high and on
the signal event when timer expires I am making another gpio pin high,
and the time between these measured varies between 10ms - 13ms i.e. it
means the timer frequency is 250Hz, which was set by default for
powerpc. So to achieve close to precise of 10ms I set the timer
frequency to 1000Hz and then I got the resolution of 10ms -10.8ms.
I would like to ask is the right approach of changing Timer Frequency
to 1000Hz from 250Hz ? ? ?
Because while searching some information regarding this I learned
about High-Res Timers. In linux-2.6.20 x86 has this feature enabled
rather you can enable it but not for powerpc arch, Right ? ? ? If yes
then is there any way to add CONFIG_HIGH_RES_TIMERS feature to
linux-2.6.20, any patch available ? ? ? =A0otherwise what could be the
option ? ? ?
In Linux by default Preemption is not enabled, CONFIG_PREEMPT_NONE=3Dy
so I tried to enabled CONFIG_PREEMPT=3Dy but when I boot the board with
preemption enabled I got the scheduling with atomic error (please
check the log below, thanks). I tried to debug and find some info but
no luck. Could anyone please explain the reason for it and how I can
fix it ? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
########################### Start #################################
NET: Registered protocol family 1
NET: Registered protocol family 17
BUG: scheduling while atomic: swapper/0x00000001/1
Call Trace:
[C07F5D50] [C0008938] =A0(unreliable)
[C07F5D80] [C02933CC]
[C07F5DD0] [C029472C]
[C07F5E10] [C0201AF0]
[C07F5E50] [C0201E08]
[C07F5E90] [C01FEE14]
[C07F5EB0] [C0202018]
[C07F5F30] [C0017490]
[C07F5F50] [C02FB4B0]
[C07F5F90] [C0003960]
[C07F5FF0] [C0010C74]
BUG: scheduling while atomic: swapper/0x00000001/1
########################## END ####################################
########################## Start ####################################
BUG: scheduling while atomic: jffs2_gcd_mtd4/0x00000004/719
Call Trace:
[C05BDBE0] [C0008938] =A0(unreliable)
[C05BDC10] [C02933CC]
[C05BDC60] [C029472C]
[C05BDCA0] [C01D9F14]
[C05BDCE0] [C01D5424]
[C05BDD40] [C01D74D4]
[C05BDD70] [C01C9330]
[C05BDD80] [C0127F88]
[C05BDDB0] [C011F26C]
[C05BDE20] [C0120320]
[C05BDE90] [C012327C]
--- Exception: 1[C05BDF50] [C0125F0C] =A0(unreliable)
[C05BDFF0] [C0010C74]
######################## END ########################################
^ permalink raw reply
* [PATCH] fsl-diu-fb: Pass the proper device for dma mapping routines
From: Anton Vorontsov @ 2009-04-04 18:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Timur Tabi, Antonino Daplas
The driver should pass a device that specifies internal DMA ops, but
currently NULL pointers are passed, and thus following bug pops up:
Freescale DIU driver
------------[ cut here ]------------
kernel BUG at arch/powerpc/include/asm/dma-mapping.h:237!
Oops: Exception in kernel mode, sig: 5 [#1]
...
NIP [c01658b4] allocate_buf+0x0/0x8
LR [c0306554] fsl_diu_probe+0x2b4/0x518
Call Trace:
[df02be10] [c030638c] fsl_diu_probe+0xec/0x518 (unreliable)
[df02be60] [c020cdec] of_platform_device_probe+0x5c/0x84
[df02be80] [c018f5d0] really_probe+0x78/0x1a0
[df02bea0] [c018f7c0] __driver_attach+0xa4/0xa8
[df02bec0] [c018ea00] bus_for_each_dev+0x60/0x9c
[df02bef0] [c018f414] driver_attach+0x24/0x34
[df02bf00] [c018f168] bus_add_driver+0x12c/0x1cc
[df02bf20] [c018fbdc] driver_register+0x6c/0x110
[df02bf30] [c020ccb4] of_register_driver+0x54/0x70
[df02bf40] [c03d0a50] fsl_diu_init+0x70/0xa4
...
This patch fixes the issue.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/video/fsl-diu-fb.c | 34 +++++++++++++++++++++-------------
1 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index fb51197..f153c58 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1352,14 +1352,15 @@ static int fsl_diu_resume(struct of_device *ofdev)
#endif /* CONFIG_PM */
/* Align to 64-bit(8-byte), 32-byte, etc. */
-static int allocate_buf(struct diu_addr *buf, u32 size, u32 bytes_align)
+static int allocate_buf(struct device *dev, struct diu_addr *buf, u32 size,
+ u32 bytes_align)
{
u32 offset, ssize;
u32 mask;
dma_addr_t paddr = 0;
ssize = size + bytes_align;
- buf->vaddr = dma_alloc_coherent(NULL, ssize, &paddr, GFP_DMA |
+ buf->vaddr = dma_alloc_coherent(dev, ssize, &paddr, GFP_DMA |
__GFP_ZERO);
if (!buf->vaddr)
return -ENOMEM;
@@ -1376,9 +1377,10 @@ static int allocate_buf(struct diu_addr *buf, u32 size, u32 bytes_align)
return 0;
}
-static void free_buf(struct diu_addr *buf, u32 size, u32 bytes_align)
+static void free_buf(struct device *dev, struct diu_addr *buf, u32 size,
+ u32 bytes_align)
{
- dma_free_coherent(NULL, size + bytes_align,
+ dma_free_coherent(dev, size + bytes_align,
buf->vaddr, (buf->paddr - buf->offset));
return;
}
@@ -1476,17 +1478,19 @@ static int __devinit fsl_diu_probe(struct of_device *ofdev,
machine_data->monitor_port = monitor_port;
/* Area descriptor memory pool aligns to 64-bit boundary */
- if (allocate_buf(&pool.ad, sizeof(struct diu_ad) * FSL_AOI_NUM, 8))
+ if (allocate_buf(&ofdev->dev, &pool.ad,
+ sizeof(struct diu_ad) * FSL_AOI_NUM, 8))
return -ENOMEM;
/* Get memory for Gamma Table - 32-byte aligned memory */
- if (allocate_buf(&pool.gamma, 768, 32)) {
+ if (allocate_buf(&ofdev->dev, &pool.gamma, 768, 32)) {
ret = -ENOMEM;
goto error;
}
/* For performance, cursor bitmap buffer aligns to 32-byte boundary */
- if (allocate_buf(&pool.cursor, MAX_CURS * MAX_CURS * 2, 32)) {
+ if (allocate_buf(&ofdev->dev, &pool.cursor, MAX_CURS * MAX_CURS * 2,
+ 32)) {
ret = -ENOMEM;
goto error;
}
@@ -1554,11 +1558,13 @@ error:
i > 0; i--)
uninstall_fb(machine_data->fsl_diu_info[i - 1]);
if (pool.ad.vaddr)
- free_buf(&pool.ad, sizeof(struct diu_ad) * FSL_AOI_NUM, 8);
+ free_buf(&ofdev->dev, &pool.ad,
+ sizeof(struct diu_ad) * FSL_AOI_NUM, 8);
if (pool.gamma.vaddr)
- free_buf(&pool.gamma, 768, 32);
+ free_buf(&ofdev->dev, &pool.gamma, 768, 32);
if (pool.cursor.vaddr)
- free_buf(&pool.cursor, MAX_CURS * MAX_CURS * 2, 32);
+ free_buf(&ofdev->dev, &pool.cursor, MAX_CURS * MAX_CURS * 2,
+ 32);
if (machine_data->dummy_aoi_virt)
fsl_diu_free(machine_data->dummy_aoi_virt, 64);
iounmap(dr.diu_reg);
@@ -1584,11 +1590,13 @@ static int fsl_diu_remove(struct of_device *ofdev)
for (i = ARRAY_SIZE(machine_data->fsl_diu_info); i > 0; i--)
uninstall_fb(machine_data->fsl_diu_info[i - 1]);
if (pool.ad.vaddr)
- free_buf(&pool.ad, sizeof(struct diu_ad) * FSL_AOI_NUM, 8);
+ free_buf(&ofdev->dev, &pool.ad,
+ sizeof(struct diu_ad) * FSL_AOI_NUM, 8);
if (pool.gamma.vaddr)
- free_buf(&pool.gamma, 768, 32);
+ free_buf(&ofdev->dev, &pool.gamma, 768, 32);
if (pool.cursor.vaddr)
- free_buf(&pool.cursor, MAX_CURS * MAX_CURS * 2, 32);
+ free_buf(&ofdev->dev, &pool.cursor, MAX_CURS * MAX_CURS * 2,
+ 32);
if (machine_data->dummy_aoi_virt)
fsl_diu_free(machine_data->dummy_aoi_virt, 64);
iounmap(dr.diu_reg);
--
1.5.6.5
^ permalink raw reply related
* [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines
From: Anton Vorontsov @ 2009-04-04 18:33 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel, Liam Girdwood, Timur Tabi
The driver should pass a device that specifies internal DMA ops, but
substream->pcm is just a logical device, and thus doesn't have arch-
specific dma callbacks, therefore following bug appears:
Freescale Synchronous Serial Interface (SSI) ASoC Driver
------------[ cut here ]------------
kernel BUG at arch/powerpc/include/asm/dma-mapping.h:237!
Oops: Exception in kernel mode, sig: 5 [#1]
...
NIP [c02259c4] snd_malloc_dev_pages+0x58/0xac
LR [c0225c74] snd_dma_alloc_pages+0xf8/0x108
Call Trace:
[df02bde0] [df02be2c] 0xdf02be2c (unreliable)
[df02bdf0] [c0225c74] snd_dma_alloc_pages+0xf8/0x108
[df02be10] [c023a100] fsl_dma_new+0x68/0x124
[df02be20] [c02342ac] soc_new_pcm+0x1bc/0x234
[df02bea0] [c02343dc] snd_soc_new_pcms+0xb8/0x148
[df02bed0] [c023824c] cs4270_probe+0x34/0x124
[df02bef0] [c0232fe8] snd_soc_instantiate_card+0x1a4/0x2f4
[df02bf20] [c0233164] snd_soc_instantiate_cards+0x2c/0x68
[df02bf30] [c0234704] snd_soc_register_platform+0x60/0x80
[df02bf50] [c03d5664] fsl_soc_platform_init+0x18/0x28
...
This patch fixes the issue by using card's device instead.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
sound/soc/fsl/fsl_dma.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
index b3eb857..835e43c 100644
--- a/sound/soc/fsl/fsl_dma.c
+++ b/sound/soc/fsl/fsl_dma.c
@@ -300,7 +300,7 @@ static int fsl_dma_new(struct snd_card *card, struct snd_soc_dai *dai,
if (!card->dev->coherent_dma_mask)
card->dev->coherent_dma_mask = fsl_dma_dmamask;
- ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev,
+ ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
fsl_dma_hardware.buffer_bytes_max,
&pcm->streams[0].substream->dma_buffer);
if (ret) {
@@ -310,7 +310,7 @@ static int fsl_dma_new(struct snd_card *card, struct snd_soc_dai *dai,
return -ENOMEM;
}
- ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev,
+ ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
fsl_dma_hardware.buffer_bytes_max,
&pcm->streams[1].substream->dma_buffer);
if (ret) {
@@ -418,7 +418,7 @@ static int fsl_dma_open(struct snd_pcm_substream *substream)
return -EBUSY;
}
- dma_private = dma_alloc_coherent(substream->pcm->dev,
+ dma_private = dma_alloc_coherent(substream->pcm->card->dev,
sizeof(struct fsl_dma_private), &ld_buf_phys, GFP_KERNEL);
if (!dma_private) {
dev_err(substream->pcm->card->dev,
@@ -445,7 +445,7 @@ static int fsl_dma_open(struct snd_pcm_substream *substream)
dev_err(substream->pcm->card->dev,
"can't register ISR for IRQ %u (ret=%i)\n",
dma_private->irq, ret);
- dma_free_coherent(substream->pcm->dev,
+ dma_free_coherent(substream->pcm->card->dev,
sizeof(struct fsl_dma_private),
dma_private, dma_private->ld_buf_phys);
return ret;
@@ -761,13 +761,13 @@ static int fsl_dma_close(struct snd_pcm_substream *substream)
free_irq(dma_private->irq, dma_private);
if (dma_private->ld_buf_phys) {
- dma_unmap_single(substream->pcm->dev,
+ dma_unmap_single(substream->pcm->card->dev,
dma_private->ld_buf_phys,
sizeof(dma_private->link), DMA_TO_DEVICE);
}
/* Deallocate the fsl_dma_private structure */
- dma_free_coherent(substream->pcm->dev,
+ dma_free_coherent(substream->pcm->card->dev,
sizeof(struct fsl_dma_private),
dma_private, dma_private->ld_buf_phys);
substream->runtime->private_data = NULL;
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/3] spi_mpc83xx: Handles other Freescale processors
From: Anton Vorontsov @ 2009-04-04 19:28 UTC (permalink / raw)
To: Kumar Gala, David Brownell; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
With this patch we'll able to select spi_mpc83xx driver on the MPC86xx
platforms. Let the driver depend on FSL_SOC, so we don't have to worry
about Kconfig anymore.
Also remove the "experimental" dependency, the driver has been tested
to work on a various hardware, and surely not experimental anymore.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83a185d..3c1845c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -140,16 +140,14 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx/QUICC Engine SPI controller"
- depends on (PPC_83xx || QUICC_ENGINE) && EXPERIMENTAL
+ tristate "Freescale MPC8xxx SPI controller"
+ depends on FSL_SOC
help
- This enables using the Freescale MPC83xx and QUICC Engine SPI
- controllers in master mode.
+ This enables using the Freescale MPC8xxx SPI controllers in master
+ mode.
- Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors, plus processors with QUICC Engine
- technology. This driver uses a simple set of shift registers for data
- (opposed to the CPM based descriptor model).
+ This driver uses a simple set of shift registers for data (opposed
+ to the CPM based descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/3] spi_mpc83xx: Quieten down the "Requested speed is too low" message
From: Anton Vorontsov @ 2009-04-04 19:28 UTC (permalink / raw)
To: Kumar Gala, David Brownell; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
When a platform is running at high frequencies it's not always
possible to scale-down a frequency to a requested value, and using
mmc_spi driver this leads to the following printk flood during card
polling:
...
mmc_spi spi32766.0: Requested speed is too low: 400000 Hz. Will use
520828 Hz instead.
mmc_spi spi32766.0: Requested speed is too low: 400000 Hz. Will use
520828 Hz instead.
...
Fix this by using WARN_ONCE(), it's better than the flood, and also
better than turning dev_err() into dev_dbg(), since we actually want
to warn that some things may not work correctly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi_mpc83xx.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index f4573a9..08b49d2 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -14,6 +14,7 @@
#include <linux/init.h>
#include <linux/types.h>
#include <linux/kernel.h>
+#include <linux/bug.h>
#include <linux/errno.h>
#include <linux/err.h>
#include <linux/completion.h>
@@ -275,12 +276,12 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi, struct spi_transfer *t)
if ((mpc83xx_spi->spibrg / hz) > 64) {
cs->hw_mode |= SPMODE_DIV16;
pm = mpc83xx_spi->spibrg / (hz * 64);
- if (pm > 16) {
- dev_err(&spi->dev, "Requested speed is too "
- "low: %d Hz. Will use %d Hz instead.\n",
- hz, mpc83xx_spi->spibrg / 1024);
+
+ WARN_ONCE(pm > 16, "%s: Requested speed is too low: %d Hz. "
+ "Will use %d Hz instead.\n", dev_name(&spi->dev),
+ hz, mpc83xx_spi->spibrg / 1024);
+ if (pm > 16)
pm = 16;
- }
} else
pm = mpc83xx_spi->spibrg / (hz * 4);
if (pm)
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/3] powerpc/86xx: Add MMC SPI support for MPC8610HPCD boards
From: Anton Vorontsov @ 2009-04-04 19:28 UTC (permalink / raw)
To: Kumar Gala, David Brownell; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
This patch adds spi and mmc-spi-slot nodes, plus a gpio-controller
for PIXIS' sdcsr bank that is used for managing SPI chip-select and
for reading card's states.
Note that spi-max-frequency is lowered since at high frequencies SD
cards don't work reliably (there is some problem with the chip select
line, it's probably quite slow because it's routed via PIXIS).
Previously there was a work around: we didn't use chip-select line
at all, but some cards don't like that, so we'd better use the low
frequency.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 32 ++++++++++++++++++++++++++++
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 4 +++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 1bd3ebe..a18fa5c 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -100,8 +100,18 @@
};
board-control@3,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,fpga-pixis";
reg = <3 0 0x20>;
+ ranges = <0 3 0 0x20>;
+
+ sdcsr_pio: gpio-controller@a {
+ #gpio-cells = <2>;
+ compatible = "fsl,fpga-pixis-gpio-bank";
+ reg = <0xa 1>;
+ gpio-controller;
+ };
};
};
@@ -164,6 +174,28 @@
interrupt-parent = <&mpic>;
};
+ spi@7000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc8610-spi", "fsl,spi";
+ reg = <0x7000 0x40>;
+ cell-index = <0>;
+ interrupts = <59 2>;
+ interrupt-parent = <&mpic>;
+ mode = "cpu";
+ gpios = <&sdcsr_pio 7 0>;
+
+ mmc-slot@0 {
+ compatible = "fsl,mpc8610hpcd-mmc-slot",
+ "mmc-spi-slot";
+ reg = <0>;
+ gpios = <&sdcsr_pio 0 1 /* nCD */
+ &sdcsr_pio 1 0>; /* WP */
+ voltage-ranges = <3300 3300>;
+ spi-max-frequency = <6000000>;
+ };
+ };
+
display@2c000 {
compatible = "fsl,diu";
reg = <0x2c000 100>;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 3f49a6f..ce64572 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -38,6 +38,7 @@
#include <linux/of_platform.h>
#include <sysdev/fsl_pci.h>
#include <sysdev/fsl_soc.h>
+#include <sysdev/simple_gpio.h>
#include "mpc86xx.h"
@@ -52,6 +53,9 @@ static struct of_device_id __initdata mpc8610_ids[] = {
static int __init mpc8610_declare_of_platform_devices(void)
{
+ /* Firstly, register PIXIS GPIOs. */
+ simple_gpiochip_init("fsl,fpga-pixis-gpio-bank");
+
/* Without this call, the SSI device driver won't get probed. */
of_platform_bus_probe(NULL, mpc8610_ids, NULL);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc/86xx: Add MMC SPI support for MPC8610HPCD boards
From: H. Peter Anvin @ 2009-04-05 0:38 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Andrew Morton, David Brownell, linux-kernel
In-Reply-To: <20090404192826.GC12183@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> This patch adds spi and mmc-spi-slot nodes, plus a gpio-controller
> for PIXIS' sdcsr bank that is used for managing SPI chip-select and
> for reading card's states.
>
> Note that spi-max-frequency is lowered since at high frequencies SD
> cards don't work reliably (there is some problem with the chip select
> line, it's probably quite slow because it's routed via PIXIS).
>
> Previously there was a work around: we didn't use chip-select line
> at all, but some cards don't like that, so we'd better use the low
> frequency.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
I have to admit being somewhat confused. The CS# line is pulled low and
stays low for the duration of a command, so it shouldn't affect the SPI
frequency, only the delay between commands.
You're saying "some cards don't like not using the CS# line" ... in
particular, I know there are hardware devices which toggle the clock at
low frequency (< 400 kHz) for a while (I think the minimum is 88 clocks
or so) and then permanently assert the CS# line before giving the
starting CMD0. Even so, the CMD0 is supposed to be sent at < 400 kHz
since the card will still be in open drain mode at that point.
Does that disagree with your observations? If so, I'd be really
interested to find out what you have seen in more detail, as it adds to
the understanding of MMC/SD cards in the field.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines
From: Grant Likely @ 2009-04-05 5:59 UTC (permalink / raw)
To: Anton Vorontsov, Becky Bruce, Kumar Gala
Cc: linuxppc-dev, alsa-devel, Mark Brown, Timur Tabi, Liam Girdwood
In-Reply-To: <20090404183319.GA22203@oksana.dev.rtsoft.ru>
Becky & Kumar,
Considering these fixups, would it be advisable for the dma functions
to climb up the dev->parent linkage when dma_ops are NULL?
g.
On Sat, Apr 4, 2009 at 12:33 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> The driver should pass a device that specifies internal DMA ops, but
> substream->pcm is just a logical device, and thus doesn't have arch-
> specific dma callbacks, therefore following bug appears:
>
> =A0Freescale Synchronous Serial Interface (SSI) ASoC Driver
> =A0------------[ cut here ]------------
> =A0kernel BUG at arch/powerpc/include/asm/dma-mapping.h:237!
> =A0Oops: Exception in kernel mode, sig: 5 [#1]
> =A0...
> =A0NIP [c02259c4] snd_malloc_dev_pages+0x58/0xac
> =A0LR [c0225c74] snd_dma_alloc_pages+0xf8/0x108
> =A0Call Trace:
> =A0[df02bde0] [df02be2c] 0xdf02be2c (unreliable)
> =A0[df02bdf0] [c0225c74] snd_dma_alloc_pages+0xf8/0x108
> =A0[df02be10] [c023a100] fsl_dma_new+0x68/0x124
> =A0[df02be20] [c02342ac] soc_new_pcm+0x1bc/0x234
> =A0[df02bea0] [c02343dc] snd_soc_new_pcms+0xb8/0x148
> =A0[df02bed0] [c023824c] cs4270_probe+0x34/0x124
> =A0[df02bef0] [c0232fe8] snd_soc_instantiate_card+0x1a4/0x2f4
> =A0[df02bf20] [c0233164] snd_soc_instantiate_cards+0x2c/0x68
> =A0[df02bf30] [c0234704] snd_soc_register_platform+0x60/0x80
> =A0[df02bf50] [c03d5664] fsl_soc_platform_init+0x18/0x28
> =A0...
>
> This patch fixes the issue by using card's device instead.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> =A0sound/soc/fsl/fsl_dma.c | =A0 12 ++++++------
> =A01 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index b3eb857..835e43c 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -300,7 +300,7 @@ static int fsl_dma_new(struct snd_card *card, struct =
snd_soc_dai *dai,
> =A0 =A0 =A0 =A0if (!card->dev->coherent_dma_mask)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0card->dev->coherent_dma_mask =3D fsl_dma_d=
mamask;
>
> - =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev,
> + =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl_dma_hardware.buffer_bytes_max,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&pcm->streams[0].substream->dma_buffer);
> =A0 =A0 =A0 =A0if (ret) {
> @@ -310,7 +310,7 @@ static int fsl_dma_new(struct snd_card *card, struct =
snd_soc_dai *dai,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -ENOMEM;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev,
> + =A0 =A0 =A0 ret =3D snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl_dma_hardware.buffer_bytes_max,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&pcm->streams[1].substream->dma_buffer);
> =A0 =A0 =A0 =A0if (ret) {
> @@ -418,7 +418,7 @@ static int fsl_dma_open(struct snd_pcm_substream *sub=
stream)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -EBUSY;
> =A0 =A0 =A0 =A0}
>
> - =A0 =A0 =A0 dma_private =3D dma_alloc_coherent(substream->pcm->dev,
> + =A0 =A0 =A0 dma_private =3D dma_alloc_coherent(substream->pcm->card->de=
v,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct fsl_dma_private), &ld_buf_ph=
ys, GFP_KERNEL);
> =A0 =A0 =A0 =A0if (!dma_private) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_err(substream->pcm->card->dev,
> @@ -445,7 +445,7 @@ static int fsl_dma_open(struct snd_pcm_substream *sub=
stream)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dev_err(substream->pcm->card->dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"can't register ISR for IR=
Q %u (ret=3D%i)\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_private->irq, ret);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->card->dev=
,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct fsl_dma_priv=
ate),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_private, dma_private->=
ld_buf_phys);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return ret;
> @@ -761,13 +761,13 @@ static int fsl_dma_close(struct snd_pcm_substream *=
substream)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0free_irq(dma_private->irq,=
dma_private);
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (dma_private->ld_buf_phys) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(substream-=
>pcm->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_unmap_single(substream-=
>pcm->card->dev,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_privat=
e->ld_buf_phys,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(dma=
_private->link), DMA_TO_DEVICE);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Deallocate the fsl_dma_private structur=
e */
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dma_free_coherent(substream->pcm->card->dev=
,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(struct fsl_dma_priv=
ate),
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dma_private, dma_private->=
ld_buf_phys);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0substream->runtime->private_data =3D NULL;
> --
> 1.5.6.5
> _______________________________________________
> 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: [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines
From: Anton Vorontsov @ 2009-04-05 8:52 UTC (permalink / raw)
To: Grant Likely
Cc: Becky Bruce, alsa-devel, Mark Brown, linuxppc-dev, Timur Tabi,
Liam Girdwood
In-Reply-To: <fa686aa40904042259h4c69e632x47a9e82393e8faef@mail.gmail.com>
On Sat, Apr 04, 2009 at 11:59:39PM -0600, Grant Likely wrote:
> Becky & Kumar,
>
> Considering these fixups, would it be advisable for the dma functions
> to climb up the dev->parent linkage when dma_ops are NULL?
pcm->dev->parent doesn't point to the proper device, so
this won't work.
> On Sat, Apr 4, 2009 at 12:33 PM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
> > The driver should pass a device that specifies internal DMA ops, but
> > substream->pcm is just a logical device, and thus doesn't have arch-
> > specific dma callbacks, therefore following bug appears:
> >
> > Freescale Synchronous Serial Interface (SSI) ASoC Driver
> > ------------[ cut here ]------------
> > kernel BUG at arch/powerpc/include/asm/dma-mapping.h:237!
> > Oops: Exception in kernel mode, sig: 5 [#1]
> > ...
> > NIP [c02259c4] snd_malloc_dev_pages+0x58/0xac
> > LR [c0225c74] snd_dma_alloc_pages+0xf8/0x108
> > Call Trace:
> > [df02bde0] [df02be2c] 0xdf02be2c (unreliable)
> > [df02bdf0] [c0225c74] snd_dma_alloc_pages+0xf8/0x108
> > [df02be10] [c023a100] fsl_dma_new+0x68/0x124
> > [df02be20] [c02342ac] soc_new_pcm+0x1bc/0x234
> > [df02bea0] [c02343dc] snd_soc_new_pcms+0xb8/0x148
> > [df02bed0] [c023824c] cs4270_probe+0x34/0x124
> > [df02bef0] [c0232fe8] snd_soc_instantiate_card+0x1a4/0x2f4
> > [df02bf20] [c0233164] snd_soc_instantiate_cards+0x2c/0x68
> > [df02bf30] [c0234704] snd_soc_register_platform+0x60/0x80
> > [df02bf50] [c03d5664] fsl_soc_platform_init+0x18/0x28
> > ...
> >
> > This patch fixes the issue by using card's device instead.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > sound/soc/fsl/fsl_dma.c | 12 ++++++------
> > 1 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> > index b3eb857..835e43c 100644
> > --- a/sound/soc/fsl/fsl_dma.c
> > +++ b/sound/soc/fsl/fsl_dma.c
> > @@ -300,7 +300,7 @@ static int fsl_dma_new(struct snd_card *card, struct snd_soc_dai *dai,
> > if (!card->dev->coherent_dma_mask)
> > card->dev->coherent_dma_mask = fsl_dma_dmamask;
> >
> > - ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev,
> > + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
> > fsl_dma_hardware.buffer_bytes_max,
> > &pcm->streams[0].substream->dma_buffer);
> > if (ret) {
> > @@ -310,7 +310,7 @@ static int fsl_dma_new(struct snd_card *card, struct snd_soc_dai *dai,
> > return -ENOMEM;
> > }
> >
> > - ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev,
> > + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, card->dev,
> > fsl_dma_hardware.buffer_bytes_max,
> > &pcm->streams[1].substream->dma_buffer);
> > if (ret) {
> > @@ -418,7 +418,7 @@ static int fsl_dma_open(struct snd_pcm_substream *substream)
> > return -EBUSY;
> > }
> >
> > - dma_private = dma_alloc_coherent(substream->pcm->dev,
> > + dma_private = dma_alloc_coherent(substream->pcm->card->dev,
> > sizeof(struct fsl_dma_private), &ld_buf_phys, GFP_KERNEL);
> > if (!dma_private) {
> > dev_err(substream->pcm->card->dev,
> > @@ -445,7 +445,7 @@ static int fsl_dma_open(struct snd_pcm_substream *substream)
> > dev_err(substream->pcm->card->dev,
> > "can't register ISR for IRQ %u (ret=%i)\n",
> > dma_private->irq, ret);
> > - dma_free_coherent(substream->pcm->dev,
> > + dma_free_coherent(substream->pcm->card->dev,
> > sizeof(struct fsl_dma_private),
> > dma_private, dma_private->ld_buf_phys);
> > return ret;
> > @@ -761,13 +761,13 @@ static int fsl_dma_close(struct snd_pcm_substream *substream)
> > free_irq(dma_private->irq, dma_private);
> >
> > if (dma_private->ld_buf_phys) {
> > - dma_unmap_single(substream->pcm->dev,
> > + dma_unmap_single(substream->pcm->card->dev,
> > dma_private->ld_buf_phys,
> > sizeof(dma_private->link), DMA_TO_DEVICE);
> > }
> >
> > /* Deallocate the fsl_dma_private structure */
> > - dma_free_coherent(substream->pcm->dev,
> > + dma_free_coherent(substream->pcm->card->dev,
> > sizeof(struct fsl_dma_private),
> > dma_private, dma_private->ld_buf_phys);
> > substream->runtime->private_data = NULL;
> > --
> > 1.5.6.5
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* booting Kernel 2.6.24.2 with u-boot 1.1.2
From: Yigal Goldberger @ 2009-04-05 11:12 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
I'm trying to upgrade my powerpc system from 2.6.14.7 to 2.6.24.2 .
I'm confused regarding the need to use a Flattened Device Tree, and not sure whether and how I should use it .Does u-boot 1.1.2 support it ?
(I migrated from ARCH=ppc to ARCH=powerpc) .
Best Regards,
Yigal Goldberger.
^ permalink raw reply
* Re: booting Kernel 2.6.24.2 with u-boot 1.1.2
From: Wolfgang Denk @ 2009-04-05 12:03 UTC (permalink / raw)
To: Yigal Goldberger; +Cc: linuxppc-dev
In-Reply-To: <673522.16603.qm@web38902.mail.mud.yahoo.com>
Dear Yigal Goldberger,
In message <673522.16603.qm@web38902.mail.mud.yahoo.com> you wrote:
>
> I'm trying to upgrade my powerpc system from 2.6.14.7 to 2.6.24.2 .
> I'm confused regarding the need to use a Flattened Device Tree, and not sure whether and how I should use it .Does u-boot 1.1.2 support it ?
> (I migrated from ARCH=ppc to ARCH=powerpc) .
U-Boot 1.1.2 nows absolutely nothing about device trees yet. I
recommend to update to current code - both for U-Boot and Linux
(Linux 2.6.24.2 is really old, too).
You probably can run a recent kernel on that old U-Boot version using
a cuImage, but it would be better to use current code.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
How can you tell when sour cream goes bad?
^ permalink raw reply
* 2.6.29-git12 : lockdep warning
From: Sachin Sant @ 2009-04-05 12:25 UTC (permalink / raw)
To: linux-kernel; +Cc: peterz, linuxppc-dev, mingo
With 2.6.29-git12 on a powerpc box i observed the following
warning
=================================
2.6.29-git12 #1
inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
yum-updatesd-he/6947 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&inode->inotify_mutex){+.+.?.}, at: [<c000000000154a04>] .inotify_inode_queue_event+0x6c/0x160
[<c000000000098198>] .lock_acquire+0x54/0x80
[<c000000000154bb0>] .inotify_inode_is_dead+0x38/0xcc
[<c0000000001319f0>] .d_kill+0x68/0xac
[<c0000000001320b4>] .shrink_dcache_memory+0x134/0x214
[<c0000000000e82fc>] .shrink_slab+0x144/0x20c
[<c0000000000e936c>] .kswapd+0x43c/0x628
[<c0000000000850e0>] .kthread+0x78/0xc4
[<c00000000002bd6c>] .kernel_thread+0x54/0x70
irq event stamp: 223781
hardirqs last enabled at (223781): [<c0000000001101c8>] .kmem_cache_alloc+0x184/0x200
hardirqs last disabled at (223780): [<c00000000010f204>] .cache_grow+0x3b0/0x48c
softirqs last enabled at (222934): [<c00000000002ba64>] .call_do_softirq+0x14/0x24
softirqs last disabled at (222923): [<c00000000002ba64>] .call_do_softirq+0x14/0x24
other info that might help us debug this:
4 locks held by yum-updatesd-he/6947:
#0: (&type->i_mutex_dir_key#4){+.+.+.}, at: [<c00000000012c53c>] .do_filp_open+0x188/0x874
#1: (&inode->inotify_mutex){+.+.?.}, at: [<c000000000154a04>] .inotify_inode_queue_event+0x6c/0x160
#2: (&ih->mutex){+.+...}, at: [<c000000000154a34>] .inotify_inode_queue_event+0x9c/0x160
#3: (&dev->ev_mutex){+.+...}, at: [<c000000000156330>] .inotify_dev_queue_event+0x50/0x1d8
stack backtrace:
Call Trace:
[c0000000541ff4f0] [c0000000000115cc] .show_stack+0x70/0x184 (unreliable)
[c0000000541ff5a0] [c000000000093a00] .print_usage_bug+0x1bc/0x1ec
[c0000000541ff650] [c000000000093dac] .mark_lock+0x37c/0x6c0
[c0000000541ff700] [c000000000094148] .mark_held_locks+0x58/0xac
[c0000000541ff790] [c000000000097f54] .lockdep_trace_alloc+0xc4/0xf4
[c0000000541ff810] [c00000000010fc24] .__kmalloc+0x98/0x25c
[c0000000541ff8b0] [c000000000156244] .kernel_event+0xbc/0x158
[c0000000541ff950] [c000000000156400] .inotify_dev_queue_event+0x120/0x1d8
[c0000000541ffa00] [c000000000154a84] .inotify_inode_queue_event+0xec/0x160
[c0000000541ffad0] [c0000000001292cc] .vfs_create+0x168/0x1e4
[c0000000541ffb70] [c00000000012c5f0] .do_filp_open+0x23c/0x874
[c0000000541ffd10] [c00000000011aecc] .do_sys_open+0x80/0x140
[c0000000541ffdc0] [c000000000161748] .compat_sys_open+0x24/0x38
[c0000000541ffe30] [c000000000008554] syscall_exit+0x0/0x40
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ 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