LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] Support internal I2S clock sources on MPC5200
From: Jon Smirl @ 2008-07-22 23:53 UTC (permalink / raw)
  To: linuxppc-dev, alsa-devel

Support internal I2S clock sources on MPC5200

Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---

 sound/soc/fsl/mpc5200_psc_i2s.c |   58 ++++++++++++++++++++++++++++++++++-----
 sound/soc/fsl/mpc5200_psc_i2s.h |   13 +++++++++
 2 files changed, 64 insertions(+), 7 deletions(-)
 create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h

diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
index 8692329..f028f61 100644
--- a/sound/soc/fsl/mpc5200_psc_i2s.c
+++ b/sound/soc/fsl/mpc5200_psc_i2s.c
@@ -23,8 +23,12 @@
 
 #include <sysdev/bestcomm/bestcomm.h>
 #include <sysdev/bestcomm/gen_bd.h>
+#include <asm/time.h>
+#include <asm/mpc52xx.h>
 #include <asm/mpc52xx_psc.h>
 
+#include "mpc5200_psc_i2s.h"
+
 MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
 MODULE_DESCRIPTION("Freescale MPC5200 PSC in I2S mode ASoC Driver");
 MODULE_LICENSE("GPL");
@@ -93,6 +97,7 @@ struct psc_i2s {
 	struct snd_soc_dai dai;
 	spinlock_t lock;
 	u32 sicr;
+	uint sysclk;
 
 	/* per-stream data */
 	struct psc_i2s_stream playback;
@@ -224,6 +229,7 @@ static int psc_i2s_hw_params(struct snd_pcm_substream *substream,
 {
 	struct snd_soc_pcm_runtime *rtd = substream->private_data;
 	struct psc_i2s *psc_i2s = rtd->dai->cpu_dai->private_data;
+	uint bits, framesync, bitclk, value;
 	u32 mode;
 
 	dev_dbg(psc_i2s->dev, "%s(substream=%p) p_size=%i p_bytes=%i"
@@ -235,15 +241,19 @@ static int psc_i2s_hw_params(struct snd_pcm_substream *substream,
 	switch (params_format(params)) {
 	case SNDRV_PCM_FORMAT_S8:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_8;
+		bits = 8;
 		break;
 	case SNDRV_PCM_FORMAT_S16_BE:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_16;
+		bits = 16;
 		break;
 	case SNDRV_PCM_FORMAT_S24_BE:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_24;
+		bits = 24;
 		break;
 	case SNDRV_PCM_FORMAT_S32_BE:
 		mode = MPC52xx_PSC_SICR_SIM_CODEC_32;
+		bits = 32;
 		break;
 	default:
 		dev_dbg(psc_i2s->dev, "invalid format\n");
@@ -251,7 +261,24 @@ static int psc_i2s_hw_params(struct snd_pcm_substream *substream,
 	}
 	out_be32(&psc_i2s->psc_regs->sicr, psc_i2s->sicr | mode);
 
-	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
+	if (psc_i2s->sysclk) {
+		framesync = bits * 2;
+		bitclk = (psc_i2s->sysclk) / (params_rate(params) * framesync);
+		
+		/* bitclk field is byte swapped due to mpc5200/b compatibility */
+		value = ((framesync - 1) << 24) |
+			(((bitclk - 1) & 0xFF) << 16) | ((bitclk - 1) & 0xFF00);
+		
+		dev_dbg(psc_i2s->dev, "%s(substream=%p) rate=%i sysclk=%i"
+			" framesync=%i bitclk=%i reg=%X\n",
+			__FUNCTION__, substream, params_rate(params), psc_i2s->sysclk,
+			framesync, bitclk, value);
+		
+		out_be32(&psc_i2s->psc_regs->ccr, value);
+		out_8(&psc_i2s->psc_regs->ctur, bits - 1);
+	}
+	
+  	snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
 
 	return 0;
 }
@@ -429,9 +456,29 @@ static int psc_i2s_set_sysclk(struct snd_soc_dai *cpu_dai,
 			      int clk_id, unsigned int freq, int dir)
 {
 	struct psc_i2s *psc_i2s = cpu_dai->private_data;
-	dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(cpu_dai=%p, dir=%i)\n",
-				cpu_dai, dir);
-	return (dir == SND_SOC_CLOCK_IN) ? 0 : -EINVAL;
+	int clkdiv, err; 
+	dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(cpu_dai=%p, freq=%u, dir=%i)\n",
+				cpu_dai, freq, dir);
+	if (dir == SND_SOC_CLOCK_OUT) {
+		psc_i2s->sysclk = freq;
+		if (clk_id == MPC52xx_CLK_CELLSLAVE) {
+			psc_i2s->sicr |= MPC52xx_PSC_SICR_CELLSLAVE | MPC52xx_PSC_SICR_GENCLK;
+		} else { /* MPC52xx_CLK_INTERNAL */
+			psc_i2s->sicr &= ~MPC52xx_PSC_SICR_CELLSLAVE;
+			psc_i2s->sicr |= MPC52xx_PSC_SICR_GENCLK;
+
+			clkdiv = ppc_proc_freq / freq;
+			err = ppc_proc_freq % freq;
+			if (err > freq / 2)
+				clkdiv++;
+
+			dev_dbg(psc_i2s->dev, "psc_i2s_set_sysclk(clkdiv %d freq error=%ldHz)\n",
+					clkdiv, (ppc_proc_freq / clkdiv - freq));
+				
+			return mpc52xx_set_psc_clkdiv(psc_i2s->dai.id + 1, clkdiv); 
+		}
+	}
+	return 0;
 }
 
 /**
@@ -784,9 +831,6 @@ static int __devinit psc_i2s_of_probe(struct of_device *op,
 	/* Configure the serial interface mode; defaulting to CODEC8 mode */
 	psc_i2s->sicr = MPC52xx_PSC_SICR_DTS1 | MPC52xx_PSC_SICR_I2S |
 			MPC52xx_PSC_SICR_CLKPOL;
-	if (of_get_property(op->node, "fsl,cellslave", NULL))
-		psc_i2s->sicr |= MPC52xx_PSC_SICR_CELLSLAVE |
-				 MPC52xx_PSC_SICR_GENCLK;
 	out_be32(&psc_i2s->psc_regs->sicr,
 		 psc_i2s->sicr | MPC52xx_PSC_SICR_SIM_CODEC_8);
 
diff --git a/sound/soc/fsl/mpc5200_psc_i2s.h b/sound/soc/fsl/mpc5200_psc_i2s.h
new file mode 100644
index 0000000..0e0a84e
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_i2s.h
@@ -0,0 +1,13 @@
+/*
+ * Freescale MPC5200 PSC in I2S mode
+ * ALSA SoC Digital Audio Interface (DAI) driver
+ *
+ */
+ 
+#ifndef __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__
+#define __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__
+
+#define MPC52xx_CLK_INTERNAL 0
+#define MPC52xx_CLK_CELLSLAVE 1
+
+#endif /* __SOUND_SOC_FSL_MPC52xx_PSC_I2S_H__ */

^ permalink raw reply related

* Re: netif_schedule and mpc5200_fec
From: David Miller @ 2008-07-22 23:36 UTC (permalink / raw)
  To: jonsmirl; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <9e4733910807221633x4385c36dod81ac3f81e242e5c@mail.gmail.com>

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 19:33:13 -0400

> On 7/22/08, David Miller <davem@davemloft.net> wrote:
> > From: "Jon Smirl" <jonsmirl@gmail.com>
> >
> > Date: Tue, 22 Jul 2008 18:54:18 -0400
> >
> >
> >  > On 7/22/08, David Miller <davem@davemloft.net> wrote:
> >  > > From: "Jon Smirl" <jonsmirl@gmail.com>
> >  > >  Date: Tue, 22 Jul 2008 17:03:32 -0400
> >  > >
> >  > >
> >  > > > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >  > >  > > I just updated to linus/master and mpc5200_fec won't boot.
> >  > >  >
> >  > >  > It does boot, but this badness looks like it is coming from this
> >  > >  > patch. I don't know enough about networking to debug it.
> >  > >
> >  > >
> >  > > I just applied the following patch from Anton Vorontsov which
> >  > >  will fix this.
> >  >
> >  > I applied this piece and still have the same error.
> >
> >
> > There are no calls to functions in mpc52xx_fec_adjust_link that
> >  can lead to __netif_schedule() any more.
> >
> >  Therefore I can't see how your backtrace is even possible.
> >
> >  Please double check that you've really applied the patch
> >  and that mpc52xx_fec_adjust_link lacks any calls to
> >  netif_*_queue() and *netif_schedule().
> 
> You're right. That patch fixes it. Another thing I brought down made
> my image file not get generated and I was using an old image.

Thanks for confirming this Jon.

^ permalink raw reply

* Re: netif_schedule and mpc5200_fec
From: Jon Smirl @ 2008-07-22 23:33 UTC (permalink / raw)
  To: David Miller; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <20080722.160718.122532549.davem@davemloft.net>

On 7/22/08, David Miller <davem@davemloft.net> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
>
> Date: Tue, 22 Jul 2008 18:54:18 -0400
>
>
>  > On 7/22/08, David Miller <davem@davemloft.net> wrote:
>  > > From: "Jon Smirl" <jonsmirl@gmail.com>
>  > >  Date: Tue, 22 Jul 2008 17:03:32 -0400
>  > >
>  > >
>  > > > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
>  > >  > > I just updated to linus/master and mpc5200_fec won't boot.
>  > >  >
>  > >  > It does boot, but this badness looks like it is coming from this
>  > >  > patch. I don't know enough about networking to debug it.
>  > >
>  > >
>  > > I just applied the following patch from Anton Vorontsov which
>  > >  will fix this.
>  >
>  > I applied this piece and still have the same error.
>
>
> There are no calls to functions in mpc52xx_fec_adjust_link that
>  can lead to __netif_schedule() any more.
>
>  Therefore I can't see how your backtrace is even possible.
>
>  Please double check that you've really applied the patch
>  and that mpc52xx_fec_adjust_link lacks any calls to
>  netif_*_queue() and *netif_schedule().

You're right. That patch fixes it. Another thing I brought down made
my image file not get generated and I was using an old image.


>
>  Thanks.
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Need stable 2.6 kernel for TQM823L
From: Thomas Maenner @ 2008-07-22 23:27 UTC (permalink / raw)
  To: Jochen Friedrich; +Cc: linuxppc-embedded
In-Reply-To: <486DF79C.1000202@scram.de>

Thanks guys for the info and pointers.
(Sorry for the late reply - Was on vacation)

-- 
Linux hackers are funny people: They count the time in patchlevels
--
Thomas Maenner
E-Mail: mailto:tmaenner@aehr.com

^ permalink raw reply

* Re: netif_schedule and mpc5200_fec
From: David Miller @ 2008-07-22 23:07 UTC (permalink / raw)
  To: jonsmirl; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <9e4733910807221554j451019a0sa711541e97fbf0aa@mail.gmail.com>

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 18:54:18 -0400

> On 7/22/08, David Miller <davem@davemloft.net> wrote:
> > From: "Jon Smirl" <jonsmirl@gmail.com>
> >  Date: Tue, 22 Jul 2008 17:03:32 -0400
> >
> >
> > > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >  > > I just updated to linus/master and mpc5200_fec won't boot.
> >  >
> >  > It does boot, but this badness looks like it is coming from this
> >  > patch. I don't know enough about networking to debug it.
> >
> >
> > I just applied the following patch from Anton Vorontsov which
> >  will fix this.
> 
> I applied this piece and still have the same error.

There are no calls to functions in mpc52xx_fec_adjust_link that
can lead to __netif_schedule() any more.

Therefore I can't see how your backtrace is even possible.

Please double check that you've really applied the patch
and that mpc52xx_fec_adjust_link lacks any calls to
netif_*_queue() and *netif_schedule().

Thanks.

^ permalink raw reply

* Re: netif_schedule and mpc5200_fec
From: Jon Smirl @ 2008-07-22 22:54 UTC (permalink / raw)
  To: David Miller; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <20080722.154201.234654750.davem@davemloft.net>

On 7/22/08, David Miller <davem@davemloft.net> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
>  Date: Tue, 22 Jul 2008 17:03:32 -0400
>
>
> > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
>  > > I just updated to linus/master and mpc5200_fec won't boot.
>  >
>  > It does boot, but this badness looks like it is coming from this
>  > patch. I don't know enough about networking to debug it.
>
>
> I just applied the following patch from Anton Vorontsov which
>  will fix this.

I applied this piece and still have the same error.

diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index b487d6f..4e4f683 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,9 +197,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
                if (priv->link == PHY_DOWN) {
                        new_state = 1;
                        priv->link = phydev->link;
-//                     netif_tx_schedule_all(dev);
-//                     netif_carrier_on(dev);
-//                     netif_start_queue(dev);
                }

        } else if (priv->link) {
@@ -207,8 +204,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
                priv->link = PHY_DOWN;
                priv->speed = 0;
                priv->duplex = -1;
-//             netif_stop_queue(dev);
-//             netif_carrier_off(dev);
        }

        if (new_state && netif_msg_link(priv))
jonsmirl@terra:~/fs$


net eth0: attached phy 0 to driver Generic PHY
Sending DHCP requests .<0>------------[ cut here ]------------
Badness at c01da570 [verbose debug info unavailable]
NIP: c01da570 LR: c015b31c CTR: c015b234
REGS: c382de70 TRAP: 0700   Not tainted  (2.6.26-efika)
MSR: 00029032 <EE,ME,IR,DR>  CR: 22000082  XER: 00000000
TASK = c3815000[4] 'events/0' THREAD: c382c000
GPR00: 00000001 c382df20 c3815000 c031e468 c38f25a0 00000000 00000000 00000000
GPR08: c382dfb4 c0330000 00000000 c031e468 2f762097 ffffffff 03ffe000 ffffffff
GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
GPR24: 00000000 00000000 c032b46c c0330000 c38a2e00 00000001 c38f2780 c38f2400
NIP [c01da570] __netif_schedule+0x3c/0xac
LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
Call Trace:
[c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
[c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
[c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
[c382df80] [c002eb0c] run_workqueue+0xb4/0x148
[c382dfa0] [c002f070] worker_thread+0x9c/0xb8
[c382dfd0] [c0032954] kthread+0x4c/0x88
[c382dff0] [c000f538] kernel_thread+0x44/0x60
Instruction dump:
7c6b1b78 3929e468 7f834800 39200002 90010024 38030024 bfa10014 40be0030
3d20c033 80099988 7c000034 5400d97e <0f000000> 2f800000 41be0054 38000001
PHY: f0003000:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.11
IP-Config: Complete:
     device=eth0, addr=192.168.1.11, mask=255.255.255.0, gw=192.168.1.1,
     host=Phytec, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.4, rootpath=


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply related

* Re: netif_schedule and mpc5200_fec
From: David Miller @ 2008-07-22 22:42 UTC (permalink / raw)
  To: jonsmirl; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <9e4733910807221403g512f6e37s6722c7950f881224@mail.gmail.com>

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 17:03:32 -0400

> On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > I just updated to linus/master and mpc5200_fec won't boot.
> 
> It does boot, but this badness looks like it is coming from this
> patch. I don't know enough about networking to debug it.

I just applied the following patch from Anton Vorontsov which
will fix this.

netdev: bunch of drivers: avoid WARN at net/core/dev.c:1328

The drivers were touching net queue before it has been started, so
without this patch, the drivers will potentially WARN at
net/core/dev.c:1328.

I don't have the hardware for the drivers below, so this patch is
untested, and thus should be carefully peer reviewed.

tc35815.c
au1000_eth.c
bfin_mac.c
macb.c
^ The four drivers are using phylib, they're calling netif_start_queue()
in open() callback. So trivially remove netif_tx_schedule_all().
Phylib will handle netif_carrier_*().

cpmac.c
fec_mpc52xx.c
fs_enet/fs_enet-main.c
sh_eth.c
^ The same as above, but these were also needlessly calling
netif_carrier_*() functions. So removed queue calls and also remove
carrier calls, since phylib will handle it. fs_enet-main.c also didn't
call netif_start_queue() at open(), this is fixed now.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/au1000_eth.c           |    5 ++---
 drivers/net/bfin_mac.c             |    1 -
 drivers/net/cpmac.c                |    2 --
 drivers/net/fec_mpc52xx.c          |    5 -----
 drivers/net/fs_enet/fs_enet-main.c |    7 ++-----
 drivers/net/macb.c                 |    4 +---
 drivers/net/sh_eth.c               |    5 -----
 drivers/net/tc35815.c              |    1 -
 8 files changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 3ab61e4..cb8be49 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -911,9 +911,8 @@ au1000_adjust_link(struct net_device *dev)
 	if(phydev->link != aup->old_link) {
 		// link state changed
 
-		if (phydev->link) // link went up
-			netif_tx_schedule_all(dev);
-		else { // link went down
+		if (!phydev->link) {
+			/* link went down */
 			aup->old_speed = 0;
 			aup->old_duplex = -1;
 		}
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index a6a3da8..a8ec60e 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -357,7 +357,6 @@ static void bfin_mac_adjust_link(struct net_device *dev)
 		if (!lp->old_link) {
 			new_state = 1;
 			lp->old_link = 1;
-			netif_tx_schedule_all(dev);
 		}
 	} else if (lp->old_link) {
 		new_state = 1;
diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
index fbd4280..a7800e5 100644
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -945,10 +945,8 @@ static void cpmac_adjust_link(struct net_device *dev)
 		if (!priv->oldlink) {
 			new_state = 1;
 			priv->oldlink = 1;
-			netif_tx_schedule_all(dev);
 		}
 	} else if (priv->oldlink) {
-		netif_tx_stop_all_queues(dev);
 		new_state = 1;
 		priv->oldlink = 0;
 		priv->oldspeed = 0;
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index ae9ecb7..4e4f683 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,9 +197,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
 		if (priv->link == PHY_DOWN) {
 			new_state = 1;
 			priv->link = phydev->link;
-			netif_tx_schedule_all(dev);
-			netif_carrier_on(dev);
-			netif_start_queue(dev);
 		}
 
 	} else if (priv->link) {
@@ -207,8 +204,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
 		priv->link = PHY_DOWN;
 		priv->speed = 0;
 		priv->duplex = -1;
-		netif_stop_queue(dev);
-		netif_carrier_off(dev);
 	}
 
 	if (new_state && netif_msg_link(priv))
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 445763e..5291188 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -738,9 +738,6 @@ static void generic_adjust_link(struct  net_device *dev)
 		if (!fep->oldlink) {
 			new_state = 1;
 			fep->oldlink = 1;
-			netif_tx_schedule_all(dev);
-			netif_carrier_on(dev);
-			netif_start_queue(dev);
 		}
 
 		if (new_state)
@@ -750,8 +747,6 @@ static void generic_adjust_link(struct  net_device *dev)
 		fep->oldlink = 0;
 		fep->oldspeed = 0;
 		fep->oldduplex = -1;
-		netif_carrier_off(dev);
-		netif_stop_queue(dev);
 	}
 
 	if (new_state && netif_msg_link(fep))
@@ -826,6 +821,8 @@ static int fs_enet_open(struct net_device *dev)
 	}
 	phy_start(fep->phydev);
 
+	netif_start_queue(dev);
+
 	return 0;
 }
 
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 0496d16..daba82b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -164,9 +164,7 @@ static void macb_handle_link_change(struct net_device *dev)
 	}
 
 	if (phydev->link != bp->link) {
-		if (phydev->link)
-			netif_tx_schedule_all(dev);
-		else {
+		if (!phydev->link) {
 			bp->speed = 0;
 			bp->duplex = -1;
 		}
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index a4bc812..c69ba13 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -642,17 +642,12 @@ static void sh_eth_adjust_link(struct net_device *ndev)
 					| ECMR_DM, ioaddr + ECMR);
 			new_state = 1;
 			mdp->link = phydev->link;
-			netif_tx_schedule_all(ndev);
-			netif_carrier_on(ndev);
-			netif_start_queue(ndev);
 		}
 	} else if (mdp->link) {
 		new_state = 1;
 		mdp->link = PHY_DOWN;
 		mdp->speed = 0;
 		mdp->duplex = -1;
-		netif_stop_queue(ndev);
-		netif_carrier_off(ndev);
 	}
 
 	if (new_state)
diff --git a/drivers/net/tc35815.c b/drivers/net/tc35815.c
index 41d3ac4..a645e50 100644
--- a/drivers/net/tc35815.c
+++ b/drivers/net/tc35815.c
@@ -672,7 +672,6 @@ static void tc_handle_link_change(struct net_device *dev)
 			if (dev->flags & IFF_PROMISC)
 				tc35815_set_multicast_list(dev);
 #endif
-			netif_tx_schedule_all(dev);
 		} else {
 			lp->speed = 0;
 			lp->duplex = -1;
-- 
1.5.6.4.433.g09651

^ permalink raw reply related

* Re: [OT] write flash on MPC5200 board via jtag
From: Jon Smirl @ 2008-07-22 22:30 UTC (permalink / raw)
  To: Albrecht Dreß; +Cc: LinuxPPC Embedded
In-Reply-To: <1216753011l.5683l.0l@antares>

On 7/22/08, Albrecht Dre=DF <albrecht.dress@arcor.de> wrote:
> Hi,
>
>  sorry for a somewhat off-topic question...
>
>  I want to design a mpc5200b board which is roughly derived from Freescal=
e's
> 5200B Lite demo.  Obviously, I have the problem to initially write u-boot
> into the boot nor flash.  I believe this would be possible using the
> jtag/bsm interface (is that true?).
>
>  Can you recommend any good hardware and software solution for that, if
> possible running on linux (OSS?)?  I don't need a "real" debugger (maybe =
an
> interface to gdb), just something to write the flash, so u-boot comes up.

I haven't tried it, but a Macraigor USB Wiggler supports the MPC5200
and it's $250.
http://www.macraigor.com/cpus.htm
That should be enough to write uboot into RAM. Once uboot is in RAM
you can use it to write the flash.

Let me know if you try it and it works.

>
>  Thanks for any help,
>  Albrecht.
>
> _______________________________________________
>  Linuxppc-embedded mailing list
>  Linuxppc-embedded@ozlabs.org
>  https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>


--=20
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: latest tree build failure -- cpm uart & gpio
From: Anton Vorontsov @ 2008-07-22 22:26 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: David Brownell, linuxppc-dev list, Kumar Gala, Linux Kernel list,
	Alan Cox
In-Reply-To: <1216764309.11027.211.camel@pasglop>

On Wed, Jul 23, 2008 at 08:05:09AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-22 at 18:53 +0400, Anton Vorontsov wrote:
> > On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote:
> > > can someone look at the following compile failure in linus's tree.  I'm 
> > > guessing part of this has to do with Alan's tty changes (and might  
> > > already be addressed?).
> > >
> > > include/asm-generic/gpio.h:131: error: implicit declaration of function 
> > > 'gpio_get_value'
> > > include/asm-generic/gpio.h:137: error: implicit declaration of function 
> > > 'gpio_set_value'
> > 
> > I think this patch should help:
> > 
> > [OF] of_gpio: should use new <linux/gpio.h> header
> > http://patchwork.ozlabs.org/linuxppc/patch?id=18750
> > 
> > David, can you please Ack it? See Benjamin's mail:
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html
> > 
> 
> Hrm.. I though I had that one in my latest batch. In fact, I just
> checked and it got merged.

Ah, great. So the issue should be fixed already... I just pulled the
Linus' tree, and it is there indeed.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* Re: latest tree build failure -- cpm uart & gpio
From: Benjamin Herrenschmidt @ 2008-07-22 22:05 UTC (permalink / raw)
  To: avorontsov
  Cc: David Brownell, linuxppc-dev list, Kumar Gala, Linux Kernel list,
	Alan Cox
In-Reply-To: <20080722145330.GA2315@polina.dev.rtsoft.ru>

On Tue, 2008-07-22 at 18:53 +0400, Anton Vorontsov wrote:
> On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote:
> > can someone look at the following compile failure in linus's tree.  I'm 
> > guessing part of this has to do with Alan's tty changes (and might  
> > already be addressed?).
> >
> > include/asm-generic/gpio.h:131: error: implicit declaration of function 
> > 'gpio_get_value'
> > include/asm-generic/gpio.h:137: error: implicit declaration of function 
> > 'gpio_set_value'
> 
> I think this patch should help:
> 
> [OF] of_gpio: should use new <linux/gpio.h> header
> http://patchwork.ozlabs.org/linuxppc/patch?id=18750
> 
> David, can you please Ack it? See Benjamin's mail:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html
> 

Hrm.. I though I had that one in my latest batch. In fact, I just
checked and it got merged.

Ben.

^ permalink raw reply

* Problems loading Linux 2.6 using PPCBug
From: Chris Collins @ 2008-07-22 21:58 UTC (permalink / raw)
  To: linuxppc-embedded

I have a Motorola (now Emerson) Prpmc800 board. I have a working
2.4.25 kernel that I can load from flash or TFTP, but I can't seem to
get a 2.6 kernel to load. I've tried 2.6.24 and an older ~2.6.16
kernel with no success.

I'm trying to use ELDK 4.2 with 2.6.24 kernel and building with the
default .config (with a new CONFIG_CMDLINE defined for my console):
make ARCH=ppc CROSS_COMPILE=ppc_74xx- prpmc800_defconfig

When I try to load the zImage.pplus file using the PPCBug boot loader
I get the following error:

PPC7-Bug>nbo 11 0,,, zImage.pplus
Network Booting from: I82559, Controller 11, Device 0
Device Name: /pci@fe000000/pci8086,1209@11,0:0,0
Loading: zImage.pplus

Client IP Address      = 10.10.1.10
Server IP Address      = 10.101.1.101
Gateway IP Address     = 10.10.1.254
Subnet IP Address Mask = 255.255.255.0
Boot File Name         = zImage.pplus
Argument File Name     =

Network Boot File load in progress... To abort hit <BREAK>
Bytes Received =&1479208, Bytes Loaded =&1479208
Bytes/Second   =&739604, Elapsed Time =2 Second(s)

Residual-Data Located at: $1FE569FC

Exception: Program (Illegal Instruction)
SRR0 =00005400 SRR1 =00083040 Vector-Offset =00700
IP     =00005400 MSR    =00003040 CR     =00000000 FPSCR  =00000000
R0     =00000000 R1     =1FE00000 R2     =00000000 R3     =1FE569FC
R4     =00005000 R5     =00000000 R6     =00000000 R7     =00000000
R8     =00000000 R9     =00000000 R10    =00000000 R11    =00000000
R12    =00000000 R13    =00000000 R14    =00000000 R15    =00000000
R16    =00000000 R17    =00000000 R18    =00000000 R19    =00000000
R20    =00000000 R21    =00000000 R22    =00000000 R23    =00000000
R24    =00000000 R25    =00000000 R26    =00000000 R27    =00000000
R28    =00000000 R29    =00000000 R30    =00000000 R31    =00000000
SPR0   =00000000 SPR1   =00000000 SPR8   =00000000 SPR9   =00000000
00005400 00000000  WORD        $00000000


I have the 'env' variable for PReP enabled... which seems to be the
usual suspect:

PPC7-Bug>env
Bug or System environment [B/S] = B?
Maximum Memory Usage (Mb, 0=AUTO) =   2?
Field Service Menu Enable [Y/N] = N?
Probe System for Supported I/O Controllers [Y/N] = Y?
Auto-Initialize of NVRAM Header Enable [Y/N] = Y?
Network PReP-Boot Mode Enable [Y/N] = Y?
SCSI Bus Reset on Debugger Startup [Y/N]   = N?
Primary SCSI Bus Negotiations Type [A/S/N] = A?
Primary SCSI Data Bus Width [W/N]          = N?
Secondary SCSI Identifier                  = "07"?
NVRAM Boot List (GEV.fw-boot-path) Boot Enable [Y/N]           = N?
NVRAM Boot List (GEV.fw-boot-path) Boot at power-up only [Y/N] = N?
NVRAM Boot List (GEV.fw-boot-path) Boot Abort Delay            = 5?
Auto Boot Enable [Y/N]           = N?
Auto Boot at power-up only [Y/N] = N?
Auto Boot Scan Enable [Y/N]      = Y?
Auto Boot Scan Device Type List  = FDISK/CDROM/TAPE/HDISK/?
Auto Boot Controller LUN   = 00?
Auto Boot Device LUN       = 00?
Auto Boot Partition Number = 00?
Auto Boot Abort Delay      = 7?
Auto Boot Default String [NULL for an empty string] = ?
ROM Boot Enable [Y/N]            = Y?
ROM Boot at power-up only [Y/N]  = Y?
ROM Boot Abort Delay             = 5?
ROM Boot Direct Starting Address = F0110000?
ROM Boot Direct Ending Address   = FFFFFFFC?
Network Auto Boot Enable [Y/N]           = N?
Network Auto Boot at power-up only [Y/N] = N?
Network Auto Boot Controller LUN = 11?
Network Auto Boot Device LUN     = 00?
Network Auto Boot Abort Delay    = 5?
Network Auto Boot Configuration Parameters Offset (NVRAM) = 00001000?
Memory Size Enable [Y/N]         = Y?
Memory Size Starting Address     = 00000000?
Memory Size Ending Address       = 08000000?
DRAM Speed in NANO Seconds       = 10?
ROM Bank A Access Speed (ns) = 150?
ROM Bank B Access Speed (ns) = 120?
DRAM Parity Enable [On-Detection/Always/Never - O/A/N]    = O?
L2Cache Parity Enable [On-Detection/Always/Never - O/A/N] = O?
PCI Interrupts Route Control Registers (PIRQ0/1/2/3) = 0A0B0E0F?
Serial Startup Code Master Enable [Y/N] = N?
Serial Startup Code LF Enable [Y/N] =     N?
Firmware Command Buffer Enable [Y/N] = N?
Firmware Command Buffer Delay  = 5?
Firmware Command Buffer :
['NULL' terminates entry]?
PPC7-Bug>

Is this a problem with PPCBug and the 2.6 kernel? Has anyone else had
success loading the 2.6 kernel using PPCBug? Does anyone have a port
of U-Boot for the Prpmc800?

Thanks in advance for your help.
Chris

^ permalink raw reply

* RE: [OT] write flash on MPC5200 board via jtag
From: Mike Timmons @ 2008-07-22 21:55 UTC (permalink / raw)
  To: Albrecht Dreß, LinuxPPC Embedded
In-Reply-To: <1216753011l.5683l.0l@antares>

If you don't have any code on the board then I can't think of how to =
write to the flash unless you have a JTAG device. I use a BDI2000 to do =
precisely what you're doing: write U-boot into virgin on-board flash on =
a design derived from the lite 5200.

The significance of the debugger is that you need something that can =
drive the microcontroller via the JTAG port and control the flash device =
write intricacies.

Pre-programming your flash device is another option.

-----Original Message-----
From: linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org] =
On Behalf Of Albrecht Dre=DF
Sent: Tuesday, July 22, 2008 1:57 PM
To: LinuxPPC Embedded
Subject: [OT] write flash on MPC5200 board via jtag

Hi,

sorry for a somewhat off-topic question...

I want to design a mpc5200b board which is roughly derived from =20
Freescale's 5200B Lite demo.  Obviously, I have the problem to =20
initially write u-boot into the boot nor flash.  I believe this would =20
be possible using the jtag/bsm interface (is that true?).

Can you recommend any good hardware and software solution for that, if =20
possible running on linux (OSS?)?  I don't need a "real" debugger =20
(maybe an interface to gdb), just something to write the flash, so =20
u-boot comes up.

Thanks for any help,
Albrecht.

^ permalink raw reply

* Re: going to OLS?
From: Grant Likely @ 2008-07-22 21:34 UTC (permalink / raw)
  To: John Linn
  Cc: Wolfgang Denk, linuxppc-dev, Sean MacLennan, Geert Uytterhoeven,
	Stefan Roese
In-Reply-To: <20080722210958.A8A9B2F8059@mail124-wa4.bigfish.com>

On Tue, Jul 22, 2008 at 03:09:55PM -0600, John Linn wrote:
> Becky Bruce wrote:
> > So,
> > 
> > There doesn't seem to be an official plan, so I'm making one....
> > Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this
> > evening.  Anybody that wants to join us welcome.
> > 
> Sounds good, I'll be there.  It will be good to put some faces to names.

I'll be there.

g.

^ permalink raw reply

* Re: [OT] write flash on MPC5200 board via jtag
From: Grant Likely @ 2008-07-22 21:29 UTC (permalink / raw)
  To: =?ISO-8859-1?Q?Albrecht_Dre=DF_, ?=; +Cc: LinuxPPC Embedded
In-Reply-To: <1216753011l.5683l.0l@antares>

On Tue, Jul 22, 2008 at 08:56:43PM +0200, =?ISO-8859-1?Q?Albrecht_Dre=DF_ wrote:
> Hi,
>
> sorry for a somewhat off-topic question...
>
> I want to design a mpc5200b board which is roughly derived from  
> Freescale's 5200B Lite demo.  Obviously, I have the problem to initially 
> write u-boot into the boot nor flash.  I believe this would be possible 
> using the jtag/bsm interface (is that true?).
>
> Can you recommend any good hardware and software solution for that, if  
> possible running on linux (OSS?)?  I don't need a "real" debugger (maybe 
> an interface to gdb), just something to write the flash, so u-boot comes 
> up.

Get yourself an Abatron BDI-3000.

g.



> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Grant Likely @ 2008-07-22 21:26 UTC (permalink / raw)
  To: linuxppc-dev, alsa-devel, liam.girdwood, timur
In-Reply-To: <20080722092646.GA7251@sirena.org.uk>

On Tue, Jul 22, 2008 at 10:26:47AM +0100, Mark Brown wrote:
> On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote:
> 
> > Here is the latest series for adding MPC5200 I2S and TI AIC26 codec
> > support to ALSA SoC.  I believe all the comments are addressed and I
> > hope that this series is now ready to be merged.  I would really like
> > to see these ones land in 2.6.27.
> 
> That might be a bit of a push given how far into the merge window we
> are and Takashi's holiday this week, though as they are new drivers
> things could be a bit more relaxed.
> 
> Takashi, I'll queue these (and other ASoC patches) for submission in
> bulk once you return.

Thanks Mark, I owe you a beer.

g.

^ permalink raw reply

* Re: [PATCH 3/3] ASoC: Staticise keyclick dev_attr in tlv320aic26
From: Grant Likely @ 2008-07-22 21:26 UTC (permalink / raw)
  To: Mark Brown; +Cc: alsa-project.org, linuxppc-dev, timur, liam.girdwood
In-Reply-To: <1216727589-19544-3-git-send-email-broonie@opensource.wolfsonmicro.com>

On Tue, Jul 22, 2008 at 12:53:09PM +0100, Mark Brown wrote:
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>

> ---
>  sound/soc/codecs/tlv320aic26.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
> index 73b7027..bed8a9e 100644
> --- a/sound/soc/codecs/tlv320aic26.c
> +++ b/sound/soc/codecs/tlv320aic26.c
> @@ -418,7 +418,7 @@ static ssize_t aic26_keyclick_set(struct device *dev,
>  	return count;
>  }
>  
> -DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set);
> +static DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set);
>  
>  /* ---------------------------------------------------------------------
>   * SPI device portion of driver: probe and release routines and SPI
> -- 
> 1.5.6.3
> 

^ permalink raw reply

* Re: [PATCH 2/3] ASoC: Export DAI and codec for TLV320AIC26
From: Grant Likely @ 2008-07-22 21:25 UTC (permalink / raw)
  To: Mark Brown; +Cc: alsa-project.org, linuxppc-dev, timur, liam.girdwood
In-Reply-To: <1216727589-19544-2-git-send-email-broonie@opensource.wolfsonmicro.com>

On Tue, Jul 22, 2008 at 12:53:08PM +0100, Mark Brown wrote:
> This fixes sparse warnings and allows non-OpenFirmware systems to attempt
> to bind to the device.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>

> ---
>  sound/soc/codecs/tlv320aic26.c |    1 +
>  sound/soc/codecs/tlv320aic26.h |    3 +++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
> index 4621fda..73b7027 100644
> --- a/sound/soc/codecs/tlv320aic26.c
> +++ b/sound/soc/codecs/tlv320aic26.c
> @@ -383,6 +383,7 @@ struct snd_soc_codec_device aic26_soc_codec_dev = {
>  	.probe = aic26_probe,
>  	.remove = aic26_remove,
>  };
> +EXPORT_SYMBOL_GPL(aic26_soc_codec_dev);
>  
>  /* ---------------------------------------------------------------------
>   * SPI device portion of driver: sysfs files for debugging
> diff --git a/sound/soc/codecs/tlv320aic26.h b/sound/soc/codecs/tlv320aic26.h
> index 62b1f22..786ba16 100644
> --- a/sound/soc/codecs/tlv320aic26.h
> +++ b/sound/soc/codecs/tlv320aic26.h
> @@ -90,4 +90,7 @@ enum aic26_wlen {
>  	AIC26_WLEN_32	= 3 << 10,
>  };
>  
> +extern struct snd_soc_dai aic26_dai;
> +extern struct snd_soc_codec_device aic26_soc_codec_dev;
> +
>  #endif /* _TLV320AIC16_H_ */
> -- 
> 1.5.6.3
> 

^ permalink raw reply

* Re: [PATCH 1/3] ASoC: Make OpenFirmware helper include file conditional
From: Grant Likely @ 2008-07-22 21:24 UTC (permalink / raw)
  To: Mark Brown; +Cc: alsa-project.org, linuxppc-dev, timur, liam.girdwood
In-Reply-To: <1216727589-19544-1-git-send-email-broonie@opensource.wolfsonmicro.com>

On Tue, Jul 22, 2008 at 12:53:07PM +0100, Mark Brown wrote:
> The OpenFirmware API headers don't build on all platforms so ensure
> that they are not included unless they are being used.
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Acked-by: Grant Likely <grant.likely@secretlab.ca>

I actually fixed this in my tree, but I forgot to roll it into the patch
before I emailed it.  Thanks.

g.

> ---
>  include/sound/soc-of-simple.h |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
> index 696fc51..a064e19 100644
> --- a/include/sound/soc-of-simple.h
> +++ b/include/sound/soc-of-simple.h
> @@ -7,6 +7,8 @@
>  #ifndef _INCLUDE_SOC_OF_H_
>  #define _INCLUDE_SOC_OF_H_
>  
> +#if defined(CONFIG_SND_SOC_OF_SIMPLE) || defined(CONFIG_SND_SOC_OF_SIMPLE_MODULE)
> +
>  #include <linux/of.h>
>  #include <sound/soc.h>
>  
> @@ -18,4 +20,6 @@ int of_snd_soc_register_platform(struct snd_soc_platform *platform,
>  				 struct device_node *node,
>  				 struct snd_soc_dai *cpu_dai);
>  
> +#endif
> +
>  #endif /* _INCLUDE_SOC_OF_H_ */
> -- 
> 1.5.6.3
> 

^ permalink raw reply

* Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Grant Likely @ 2008-07-22 21:23 UTC (permalink / raw)
  To: linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl, timur
In-Reply-To: <20080722100951.GB2572@rakim.wolfsonmicro.main>

On Tue, Jul 22, 2008 at 11:09:52AM +0100, Mark Brown wrote:
> On Tue, Jul 22, 2008 at 12:53:58AM -0600, Grant Likely wrote:
> 
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> 
> There's a few issues that were raised on the previous review cycle that
> still need to be addressed but they should be fixable in incremental
> patches (and easier to review that way):
> 
> > +static int psc_i2s_trigger(struct snd_pcm_substream *substream, int cmd)
> 
> > +		spin_lock_irqsave(&psc_i2s->lock, flags);
> > +		/* first make sure it is low */
> > +		while ((in_8(&regs->ipcr_acr.ipcr) & 0x80) != 0)
> > +			;
> > +		/* then wait for the transition to high */
> > +		while ((in_8(&regs->ipcr_acr.ipcr) & 0x80) == 0)
> > +			;
> 
> These loops should really have some sort of time limit on them,
> otherwise they'll lock hard if the expected events don't happen.  Given
> that in slave mode they're synchronising with an externally generated
> clock this is something that might happen in practice and should produce
> better diagnostics.

Yes, I hope to rework these two lines entirely.  I'm not happy with the
current implementation either.

> > +	default:
> > +		dev_dbg(psc_i2s->dev, "invalid command\n");
> > +		return -EINVAL;
> > +	}
> 
> I'd really expect to see the other possible triggers handled, even if
> the appropriate action is to silently ignore them, rather than having
> them generate an error message.

Okay, I'll do that.

g.

^ permalink raw reply

* Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely @ 2008-07-22 21:21 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie, timur, liam.girdwood
In-Reply-To: <9e4733910807220938k7452f40co8d51e4b03e79ee8b@mail.gmail.com>

On Tue, Jul 22, 2008 at 12:38:30PM -0400, Jon Smirl wrote:
> On 7/22/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> >  +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
> >  +                             void *codec_data, struct snd_soc_dai *dai,
> >  +                             struct device_node *node);
> >  +
> >  +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
> >  +                                struct device_node *node,
> >  +                                struct snd_soc_dai *cpu_dai);
> >  +
> 
> This doesn't compile for me.  Where is struct snd_soc_dai being defined?
> 
> It used to be....
> 
> +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
> +			      void *codec_data, struct snd_soc_codec_dai *dai,
> +			      struct device_node *node);
> +
> +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
> +				 struct device_node *node,
> +				 struct snd_soc_cpu_dai *cpu_dai);
> 

I had to change it to match what is in Linus' current top of tree.  The
snd_soc_cpu_dai and snd_soc_codec_dai structures have been merged.

g.

^ permalink raw reply

* Re: netif_schedule and mpc5200_fec
From: David Miller @ 2008-07-22 21:11 UTC (permalink / raw)
  To: jonsmirl; +Cc: davem, Linuxppc-dev, netdev
In-Reply-To: <9e4733910807221403g512f6e37s6722c7950f881224@mail.gmail.com>

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 17:03:32 -0400

> On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > I just updated to linus/master and mpc5200_fec won't boot.
> 
> It does boot, but this badness looks like it is coming from this
> patch. I don't know enough about networking to debug it.

The driver is doing a netif_wake_queue() when it should not.
I'll have a more detailed look at this and try to fix it
later.

^ permalink raw reply

* RE: going to OLS?
From: John Linn @ 2008-07-22 21:09 UTC (permalink / raw)
  To: Becky Bruce, Sean MacLennan, grant.likely, Wolfgang Denk,
	Stefan Roese, Geert Uytterhoeven
  Cc: linuxppc-dev
In-Reply-To: <3A268FF3-E574-44A6-B975-92D98C553603@freescale.com>

Sounds good, I'll be there.  It will be good to put some faces to names.

Cheers,
John

> -----Original Message-----
> From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of Becky Bruce
> Sent: Tuesday, July 22, 2008 8:55 AM
> To: Sean MacLennan; grant.likely@secretlab.ca; Wolfgang Denk; Stefan
Roese; Geert Uytterhoeven
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: going to OLS?
> =

> So,
> =

> There doesn't seem to be an official plan, so I'm making one....
> Kumar, Andy, and I will be at the Black Thorn at 7:30-ish this
> evening.  Anybody that wants to join us welcome.
> =

> Cheers,
> Becky
> =

> =

> On Jul 21, 2008, at 4:24 PM, Sean MacLennan wrote:
> =

> > On Mon, 21 Jul 2008 14:15:53 -0600
> > "Grant Likely" <grant.likely@secretlab.ca> wrote:
> >
> >> BTW, if anyone else wants to receive the contact phone list, then
> >> send
> >> me your phone number ASAP.  I'll be sending it out this evening.
> >
> > My home phone number is 613-728-1680.
> >
> > Cheers,
> >  Sean
> > _______________________________________________
> > 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


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

^ permalink raw reply

* Re: netif_schedule and mpc5200_fec
From: Jon Smirl @ 2008-07-22 21:03 UTC (permalink / raw)
  To: ppc-dev, netdev, David S. Miller
In-Reply-To: <9e4733910807221247r38509c76uf625195b712a1145@mail.gmail.com>

On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> I just updated to linus/master and mpc5200_fec won't boot.

It does boot, but this badness looks like it is coming from this
patch. I don't know enough about networking to debug it.

jonsmirl@terra:~/fs/drivers/net$ git diff
8b9835108f68938a5f7e74fd2c0fc65da2abad92 fec_mpc52xx.c
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 329edd9..ae9ecb7 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,7 +197,7 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
                if (priv->link == PHY_DOWN) {
                        new_state = 1;
                        priv->link = phydev->link;
-                       netif_schedule(dev);
+                       netif_tx_schedule_all(dev);
                        netif_carrier_on(dev);
                        netif_start_queue(dev);
                }
jonsmirl@terra:~/fs/drivers/net$


>
>  Guessing it is this patch but I haven't looked at it yet.
>
>  commit 263ba3204a434d0ca851e1321b31cd58376b86cb
>  Author: David S. Miller <davem@davemloft.net>
>  Date:   Tue Jul 15 03:47:41 2008 -0700
>
>     netdev: Convert all drivers away from netif_schedule().
>
>     They logically all want to trigger a schedule for all device
>     TX queues.
>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>  Sending DHCP requests .<0>------------[ cut here ]------------
>  Badness at c01da570 [verbose debug info unavailable]
>  NIP: c01da570 LR: c015b31c CTR: c015b234
>  REGS: c382de70 TRAP: 0700   Not tainted  (2.6.26-efika)
>  MSR: 00029032 <EE,ME,IR,DR>  CR: 22000082  XER: 00000000
>  TASK = c3815000[4] 'events/0' THREAD: c382c000
>  GPR00: 00000001 c382df20 c3815000 c031e468 c38f25a0 00000000 00000000 00000000
>  GPR08: c382dfb4 c0330000 00000000 c031e468 3181b461 ffffffff 03ffe000 ffffffff
>  GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
>  GPR24: 00000000 00000000 c032b46c c0330000 c38a2e00 00000001 c38f2780 c38f2400
>  NIP [c01da570] __netif_schedule+0x3c/0xac
>  LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
>  Call Trace:
>  [c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
>  [c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
>  [c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
>  [c382df80] [c002eb0c] run_workqueue+0xb4/0x148
>  [c382dfa0] [c002f070] worker_thread+0x9c/0xb8
>  [c382dfd0] [c0032954] kthread+0x4c/0x88
>  [c382dff0] [c000f538] kernel_thread+0x44/0x60
>  Instruction dump:
>  7c6b1b78 3929e468 7f834800 39200002 90010024 38030024 bfa10014 40be0030
>  3d20c033 80099988 7c000034 5400d97e <0f000000> 2f800000 41be0054 38000001
>  PHY: f0003000:00 - Link is Up - 100/Full
>  ., OK
>
>
>
>  --
>  Jon Smirl
>  jonsmirl@gmail.com
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply related

* Re: bug: mutex_lock() in interrupt conntext via phy_stop() in gianfar
From: Sebastian Siewior @ 2008-07-22 20:59 UTC (permalink / raw)
  To: Nate Case; +Cc: netdev, Sebastian Siewior, linuxppc-dev, Vitaly Bordug, Li Yang
In-Reply-To: <1216681028.7559.993.camel@localhost.localdomain>

* Nate Case | 2008-07-21 17:57:08 [-0500]:

>On Fri, 2008-07-18 at 14:10 +0200, Sebastian Siewior wrote:
>> Commit 35b5f6b1a aka [PHYLIB: Locking fixes for PHY I/O potentially sleeping]
>> changed the phydev->lock from spinlock into a mutex. Now, the following
>> code path got triggered while NFS was unavailable:
>> 
>[snip]
>> |[  194.864733] BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/kernel/mutex.c:87
>> |[  194.875529] in_atomic():1, irqs_disabled():0
>> |[  194.879805] Call Trace:
>> |[  194.882250] [c0383d90] [c0006dd8] show_stack+0x48/0x184 (unreliable)
>> |[  194.888649] [c0383db0] [c001e938] __might_sleep+0xe0/0xf4
>> |[  194.894069] [c0383dc0] [c025a43c] mutex_lock+0x24/0x3c
>> |[  194.899234] [c0383de0] [c019005c] phy_stop+0x20/0x70
>> |[  194.904234] [c0383df0] [c018d4ec] stop_gfar+0x28/0xf4
>> |[  194.909305] [c0383e10] [c018e8c4] gfar_timeout+0x30/0x60
>> |[  194.914638] [c0383e20] [c01fe7c0] dev_watchdog+0xa8/0x144
>
>Hmm..  I'm not sure what the best solution is to this.  Make the
>stop_gfar() call happen in a workqueue, and make a similar change to
>ucc_geth, fec_mpc52xx, and fs_enet? Modify phy_stop() to do the work in
>a workqueue conditionally if in interrupt context?  Between these two
>I'd lean toward the latter.
>
>Does anyone have any better ideas?
If I look at tg3.c than exactly this is done. Others call it only on
close(). I guess this depends very much on driver's logic :)
If nobody minds, than I would assume that tg3.c is a good example and I
would move the timout path into a workqueu.

Sebastian

^ permalink raw reply

* Re: latest tree build failure -- cpm uart & gpio
From: Anton Vorontsov @ 2008-07-22 20:48 UTC (permalink / raw)
  To: David Brownell; +Cc: linuxppc-dev list, Kumar Gala, Linux Kernel list, Alan Cox
In-Reply-To: <200807221233.16723.david-b@pacbell.net>

On Tue, Jul 22, 2008 at 12:33:16PM -0700, David Brownell wrote:
> On Tuesday 22 July 2008, Anton Vorontsov wrote:
> > On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote:
> > > can someone look at the following compile failure in linus's tree.  I'm 
> > > guessing part of this has to do with Alan's tty changes (and might  
> > > already be addressed?).
> > >
> > > include/asm-generic/gpio.h:131: error: implicit declaration of function 
> > > 'gpio_get_value'
> > > include/asm-generic/gpio.h:137: error: implicit declaration of function 
> > > 'gpio_set_value'
> > 
> > I think this patch should help:
> > 
> > [OF] of_gpio: should use new <linux/gpio.h> header
> > http://patchwork.ozlabs.org/linuxppc/patch?id=18750
> 
> Is that confirmed as fixing this, vs just being the Right Thing To Do?

Just applied the patch locally and the issue is not reproducible
anymore.

> > David, can you please Ack it? See Benjamin's mail:
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html
> 
> If you like ... but this is an OF-specific change, making
> it conform with the interface spec, so I wouldn't expect
> this to need more approvals than it's already got.
> 
> Acked-by: David Brownell <dbrownell@users.sourceforge.net>

Thanks.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox