LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Heiko Schocher @ 2008-01-10  8:14 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <20080109182038.GA4337@loki.buserror.net>

Hello Scott,

Scott Wood wrote:
> On Wed, Jan 09, 2008 at 01:58:49PM +0100, Heiko Schocher wrote:
>> @@ -1312,6 +1312,9 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
>>  	       ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
>>  	       ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);
>>
>> +	/* to initialize the fep->cur_rx,... */
>> +	/* not doing this, will cause a crash in fs_enet_rx_napi */
>> +	fs_init_bds(ndev);
>>  	return 0;
> 
> We don't want to allocate ring buffers for network interfaces that are never
> opened, especially given the small amount of memory on some boards that use
> this driver.
> 
> Instead, we should probably not be calling napi_enable() until the link is
> up and init_bds() has been called.

Ah, okay. I actually tried calling fs_init_bds(ndev); in fs_enet_open() after
napi_enable, and this also works fine. I think there is the better place for
it. Thanks.

> 
>> @@ -1342,9 +1345,13 @@ static int fs_enet_remove(struct of_device *ofdev)
>>  }
>>
>>  static struct of_device_id fs_enet_match[] = {
>> -#ifdef CONFIG_FS_ENET_HAS_SCC
>> +#if defined(CONFIG_FS_ENET_HAS_SCC)
>>  	{
>> +#if defined(CONFIG_CPM1)
>>  		.compatible = "fsl,cpm1-scc-enet",
>> +#else
>> +		.compatible = "fsl,cpm2-scc-enet",
>> +#endif
> 
> I know there are already ifdefs of this sort, and that multiplatform
> cpm1/cpm2 is very unlikely to ever happen, but can we try to avoid
> introducing more such ifdefs?
> 
> We can have both match entries present at the same time.

OK, fix this.

> 
>>  		.data = (void *)&fs_scc_ops,
>>  	},
>>  #endif
>> diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
>> index 48f2f30..3b5ca76 100644
>> --- a/drivers/net/fs_enet/mac-scc.c
>> +++ b/drivers/net/fs_enet/mac-scc.c
>> @@ -50,6 +50,7 @@
>>  #include "fs_enet.h"
>>
>>  /*************************************************/
>> +#define SCC_EB ((u_char)0x10)  /* Set big endian byte order */
> 
> This is already defined in asm-powerpc/commproc.h, and thus will cause a
> duplicate definition when building for 8xx.  Please add this definition to
> asm-powerpc/cpm2.h.

OK, will fix it.

> 
>> +#if defined(CONFIG_CPM1)
>>  	W16(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | (op << 8));
>>  	for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
>>  		if ((R16(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
>>  			return 0;
>> +#else
>> +	W32(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | op);
>> +	for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
>> +		if ((R32(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
>> +			return 0;
>> +
>> +#endif
> 
> Commit 362f9b6fa8c9670cc5496390845021c2865d049b in Paul's tree makes this
> unnecessary.

Tried this patch, works fine for me :-)

> 
>> @@ -306,8 +317,15 @@ static void restart(struct net_device *dev)
>>
>>  	/* Initialize function code registers for big-endian.
>>  	 */
>> +#ifdef CONFIG_CPM2
>> +	/* from oldstyle driver in arch/ppc */
>> +	/* seems necessary */
>> +	W8(ep, sen_genscc.scc_rfcr, SCC_EB | 0x20);
>> +	W8(ep, sen_genscc.scc_tfcr, SCC_EB | 0x20);
>> +#else
>>  	W8(ep, sen_genscc.scc_rfcr, SCC_EB);
>>  	W8(ep, sen_genscc.scc_tfcr, SCC_EB);
>> +#endif
> 
> Please define 0x20 as SCC_GBL (Snooping Enabled) in cpm2.h, and
> conditionalize this on #ifndef CONFIG_NOT_COHERENT_CACHE.
> 
> You can remove the comment; it's really necessary, not just "seems" so. :-)

OK, fix it.

Will resend this fixed patch.

thanks
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply

* Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
From: Heiko Schocher @ 2008-01-10  9:06 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <4785D3D8.7080300@denx.de>

Hello Scott,

Heiko Schocher wrote:
> Hello Scott,
[...]
> Will resend this fixed patch.

Here it is:

[POWERPC] Fix Ethernet over SCC on a CPM2,
          also Fix crash in fs_enet_rx_napi()

Signed-off-by: Heiko Schocher <hs@denx.de>

diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index f2a4d39..f432a18 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -810,6 +810,10 @@ static int fs_enet_open(struct net_device *dev)
 	if (fep->fpi->use_napi)
 		napi_enable(&fep->napi);

+	/* to initialize the fep->cur_rx,... */
+	/* not doing this, will cause a crash in fs_enet_rx_napi */
+	fs_init_bds(fep->ndev);
+
 	/* Install our interrupt handler. */
 	r = fs_request_irq(dev, fep->interrupt, "fs_enet-mac", fs_enet_interrupt);
 	if (r != 0) {
@@ -982,6 +986,7 @@ static struct net_device *fs_init_instance(struct device *dev,
 	fep = netdev_priv(ndev);

 	fep->dev = dev;
+	fep->ndev = ndev;
 	dev_set_drvdata(dev, ndev);
 	fep->fpi = fpi;
 	if (fpi->init_ioports)
@@ -1085,7 +1090,6 @@ static struct net_device *fs_init_instance(struct device *dev,
 	}
 	registered = 1;

-
 	return ndev;

 err:
@@ -1347,6 +1351,10 @@ static struct of_device_id fs_enet_match[] = {
 		.compatible = "fsl,cpm1-scc-enet",
 		.data = (void *)&fs_scc_ops,
 	},
+	{
+		.compatible = "fsl,cpm2-scc-enet",
+		.data = (void *)&fs_scc_ops,
+	},
 #endif
 #ifdef CONFIG_FS_ENET_HAS_FCC
 	{
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index fe3d8a6..3889271 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -50,7 +50,6 @@
 #include "fs_enet.h"

 /*************************************************/
-
 #if defined(CONFIG_CPM1)
 /* for a 8xx __raw_xxx's are sufficient */
 #define __fs_out32(addr, x)	__raw_writel(x, addr)
@@ -65,6 +64,8 @@
 #define __fs_out16(addr, x)	out_be16(addr, x)
 #define __fs_in32(addr)	in_be32(addr)
 #define __fs_in16(addr)	in_be16(addr)
+#define __fs_out8(addr, x)	out_8(addr, x)
+#define __fs_in8(addr)	in_8(addr)
 #endif

 /* write, read, set bits, clear bits */
@@ -297,8 +298,13 @@ static void restart(struct net_device *dev)

 	/* Initialize function code registers for big-endian.
 	 */
+#ifndef CONFIG_NOT_COHERENT_CACHE
+	W8(ep, sen_genscc.scc_rfcr, SCC_EB | SCC_GBL);
+	W8(ep, sen_genscc.scc_tfcr, SCC_EB | SCC_GBL);
+#else
 	W8(ep, sen_genscc.scc_rfcr, SCC_EB);
 	W8(ep, sen_genscc.scc_tfcr, SCC_EB);
+#endif

 	/* Set maximum bytes per receive buffer.
 	 * This appears to be an Ethernet frame size, not the buffer
diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
index f1112c1..14c6496 100644
--- a/include/asm-powerpc/cpm2.h
+++ b/include/asm-powerpc/cpm2.h
@@ -375,6 +375,11 @@ typedef struct scc_param {
 	uint	scc_tcrc;	/* Internal */
 } sccp_t;

+/* Function code bits.
+*/
+#define SCC_EB	((u_char) 0x10)	/* Set big endian byte order */
+#define SCC_GBL	((u_char) 0x20) /* Snooping enabled */
+
 /* CPM Ethernet through SCC1.
  */
 typedef struct scc_enet {

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply related

* Re: add phy-handle property for fec_mpc52xx
From: David Woodhouse @ 2008-01-10  9:14 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Olaf Hering, linuxppc-dev
In-Reply-To: <18309.33088.653225.116715@cargo.ozlabs.ibm.com>


On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
> 
> > It would be much better if the kernel would 'just work'. The ideal way
> > of achieving that is for the firmware to be fixed -- but that's been
> > promised for a long time now, and we just don't believe you any more. So
> > working round it in the kernel seems to be the next best option.
> 
> Does the efika use a boot wrapper?  If so then putting the fixup in
> the boot wrapper might be better.

No, it doesn't (at least for Fedora) -- we use yaboot. Perhaps we could
make yaboot run the fixups?

-- 
dwmw2

^ permalink raw reply

* Re: [patch 4/4 v3] PS3: Add logical performance monitor driver support
From: Geert Uytterhoeven @ 2008-01-10  9:44 UTC (permalink / raw)
  To: Geoff Levand; +Cc: linuxppc-dev, paulus, Takashi Yamamoto
In-Reply-To: <47856E80.2080209@am.sony.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 822 bytes --]

On Wed, 9 Jan 2008, Geoff Levand wrote:
> --- /dev/null
> +++ b/drivers/ps3/ps3-lpm.c

> + * @node_id: The node id of a BE prosessor whos performance monitor this
                                              ^^^^
					      whose

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* Re: Linux for ml310
From: Joachim Meyer @ 2008-01-10 10:13 UTC (permalink / raw)
  To: linuxppc-embedded

Hi again

I tried my compiled kernel this morning.
I loaded my Bitstream onto the FPGA, then the zImage.elf via xmd: dow zIma=
ge.elf.
After I typed "run" I got foolowing message on an Terminal:
------------------------------------------------------------------------
loaded at:     00400000 004F219C
board data at: 004F0120 004F019C
relocated to:  00404048 004040C4
zimage at:     00404E39 004EF931
avail ram:     004F3000 10000000

Linux/PPC load: console=3DttyS0,9600
Uncompressing Linux...done.
Now booting the kernel

------------------------------------------------------------------------
Doesn't look that bad I think. ;)
The Question I have is of course why he stops there.
Is it why He can't find a rootfs=3F
Or would he say this in that case.
I found someone with an similar Problem:
http://lists.ppckernel.org/pipermail/ppckernel/2006-May/000026.html
but I already use the xparameters=5Fml310 from my BSP.
Where must I look for the error=3F
There where some warnings when I compiled the kernel. Is this ok=3F

Greets & THX
Joachim

PS: My xparameters=5Fml310.h
--------------------------------------------------------------------------=
----------------------------------------------
/*******************************************************************
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 9.1.02 EDK=5FJ=5FSP2.4
* DO NOT EDIT.
*
* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.=20
*=20
* Description: Driver parameters
*
*******************************************************************/

/* Definitions for driver UARTLITE */
#define XPAR=5FXUARTLITE=5FNUM=5FINSTANCES 1

/* Definitions for peripheral RS232=5FUART */
#define XPAR=5FRS232=5FUART=5FBASEADDR 0x40600000
#define XPAR=5FRS232=5FUART=5FHIGHADDR 0x4060FFFF
#define XPAR=5FRS232=5FUART=5FDEVICE=5FID 0
#define XPAR=5FRS232=5FUART=5FBAUDRATE 9600
#define XPAR=5FRS232=5FUART=5FUSE=5FPARITY 0
#define XPAR=5FRS232=5FUART=5FODD=5FPARITY 0
#define XPAR=5FRS232=5FUART=5FDATA=5FBITS 8


/******************************************************************/

/* Definitions for driver SPI */
#define XPAR=5FXSPI=5FNUM=5FINSTANCES 1

/* Definitions for peripheral SPI=5FEEPROM */
#define XPAR=5FSPI=5FEEPROM=5FBASEADDR 0x4B308000
#define XPAR=5FSPI=5FEEPROM=5FHIGHADDR 0x4B30807F
#define XPAR=5FSPI=5FEEPROM=5FDEVICE=5FID 0
#define XPAR=5FSPI=5FEEPROM=5FFIFO=5FEXIST 1
#define XPAR=5FSPI=5FEEPROM=5FSPI=5FSLAVE=5FONLY 0
#define XPAR=5FSPI=5FEEPROM=5FNUM=5FSS=5FBITS 1


/******************************************************************/

/* Definitions for driver PCI */
#define XPAR=5FXPCI=5FNUM=5FINSTANCES 1

/* Definitions for peripheral PCI32=5FBRIDGE */
#define XPAR=5FPCI32=5FBRIDGE=5FDEVICE=5FID 0
#define XPAR=5FPCI32=5FBRIDGE=5FBASEADDR 0x42600000
#define XPAR=5FPCI32=5FBRIDGE=5FHIGHADDR 0x4260FFFF
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5F0 0x00000000
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5FLEN=5F0 7
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR2IPIF=5F0 0
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5FENDIAN=5FTRANSLATE=5FEN=5F0 0
#define XPAR=5FPCI32=5FBRIDGE=5FPCI=5FPREFETCH=5F0 1
#define XPAR=5FPCI32=5FBRIDGE=5FPCI=5FSPACETYPE=5F0 1
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5F1 0xffffffff
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5FLEN=5F1 20
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR2IPIF=5F1 0
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5FENDIAN=5FTRANSLATE=5FEN=5F1 0
#define XPAR=5FPCI32=5FBRIDGE=5FPCI=5FPREFETCH=5F1 1
#define XPAR=5FPCI32=5FBRIDGE=5FPCI=5FSPACETYPE=5F1 1
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5F2 0xffffffff
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5FLEN=5F2 20
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR2IPIF=5F2 0
#define XPAR=5FPCI32=5FBRIDGE=5FPCIBAR=5FENDIAN=5FTRANSLATE=5FEN=5F2 0
#define XPAR=5FPCI32=5FBRIDGE=5FPCI=5FPREFETCH=5F2 1
#define XPAR=5FPCI32=5FBRIDGE=5FPCI=5FSPACETYPE=5F2 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5F0 0x60000000
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FHIGHADDR=5F0 0x7fffffff
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR2PCI=5F0 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5FENDIAN=5FTRANSLATE=5FEN=5F0 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FPREFETCH=5F0 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FSPACETYPE=5F0 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5F1 0x54000000
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FHIGHADDR=5F1 0x57ffffff
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR2PCI=5F1 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5FENDIAN=5FTRANSLATE=5FEN=5F1 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FPREFETCH=5F1 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FSPACETYPE=5F1 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5F2 0xffffffff
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FHIGHADDR=5F2 0x00000000
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR2PCI=5F2 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5FENDIAN=5FTRANSLATE=5FEN=5F2 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FPREFETCH=5F2 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FSPACETYPE=5F2 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5F3 0xffffffff
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FHIGHADDR=5F3 0x00000000
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR2PCI=5F3 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5FENDIAN=5FTRANSLATE=5FEN=5F3 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FPREFETCH=5F3 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FSPACETYPE=5F3 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5F4 0xffffffff
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FHIGHADDR=5F4 0x00000000
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR2PCI=5F4 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5FENDIAN=5FTRANSLATE=5FEN=5F4 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FPREFETCH=5F4 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FSPACETYPE=5F4 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5F5 0xffffffff
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FHIGHADDR=5F5 0x00000000
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR2PCI=5F5 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIFBAR=5FENDIAN=5FTRANSLATE=5FEN=5F5 0
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FPREFETCH=5F5 1
#define XPAR=5FPCI32=5FBRIDGE=5FIPIF=5FSPACETYPE=5F5 1
#define XPAR=5FPCI32=5FBRIDGE=5FDMA=5FBASEADDR 0xFFFFFFFF
#define XPAR=5FPCI32=5FBRIDGE=5FDMA=5FHIGHADDR 0x00000000
#define XPAR=5FPCI32=5FBRIDGE=5FDMA=5FCHAN=5FTYPE 9
#define XPAR=5FPCI32=5FBRIDGE=5FDMA=5FLENGTH=5FWIDTH 13
#define XPAR=5FPCI32=5FBRIDGE=5FBRIDGE=5FIDSEL=5FADDR=5FBIT 16


/******************************************************************/

#define XPAR=5FXSYSACE=5FMEM=5FWIDTH 8
/* Definitions for driver SYSACE */
#define XPAR=5FXSYSACE=5FNUM=5FINSTANCES 1

/* Definitions for peripheral SYSACE=5FCOMPACTFLASH */
#define XPAR=5FSYSACE=5FCOMPACTFLASH=5FBASEADDR 0x41800000
#define XPAR=5FSYSACE=5FCOMPACTFLASH=5FHIGHADDR 0x4180FFFF
#define XPAR=5FSYSACE=5FCOMPACTFLASH=5FDEVICE=5FID 0
#define XPAR=5FSYSACE=5FCOMPACTFLASH=5FMEM=5FWIDTH 8


/******************************************************************/

#define XPAR=5FINTC=5FMAX=5FNUM=5FINTR=5FINPUTS 12
#define XPAR=5FXINTC=5FHAS=5FIPR 1
#define XPAR=5FXINTC=5FUSE=5FDCR 0
/* Definitions for driver INTC */
#define XPAR=5FXINTC=5FNUM=5FINSTANCES 1

/* Definitions for peripheral OPB=5FINTC=5F0 */
#define XPAR=5FOPB=5FINTC=5F0=5FBASEADDR 0x41200000
#define XPAR=5FOPB=5FINTC=5F0=5FHIGHADDR 0x4120FFFF
#define XPAR=5FOPB=5FINTC=5F0=5FDEVICE=5FID 0
#define XPAR=5FOPB=5FINTC=5F0=5FKIND=5FOF=5FINTR 0x00000C00


/******************************************************************/

#define XPAR=5FINTC=5FSINGLE=5FBASEADDR 0x41200000
#define XPAR=5FINTC=5FSINGLE=5FHIGHADDR 0x4120FFFF
#define XPAR=5FINTC=5FSINGLE=5FDEVICE=5FID XPAR=5FOPB=5FINTC=5F0=5FDEVICE=5FID
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FSBR=5FINT=5FMASK 0X000001
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FSBR=5FINT=5FINTR 0
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTF=5FMASK 0X000002
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTF=5FINTR 1
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTE=5FMASK 0X000004
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTE=5FINTR 2
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTD=5FMASK 0X000008
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTD=5FINTR 3
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTC=5FMASK 0X000010
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTC=5FINTR 4
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTB=5FMASK 0X000020
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTB=5FINTR 5
#define XPAR=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTA=5FMASK 0X000040
#define XPAR=5FOPB=5FINTC=5F0=5FSYSTEM=5FFPGA=5F0=5FPCI32=5FBRIDGE=5FPCI=5FINTA=5FINTR 6
#define XPAR=5FSYSACE=5FCOMPACTFLASH=5FSYSACE=5FIRQ=5FMASK 0X000080
#define XPAR=5FOPB=5FINTC=5F0=5FSYSACE=5FCOMPACTFLASH=5FSYSACE=5FIRQ=5FINTR 7
#define XPAR=5FPCI32=5FBRIDGE=5FIP2INTC=5FIRPT=5FMASK 0X000100
#define XPAR=5FOPB=5FINTC=5F0=5FPCI32=5FBRIDGE=5FIP2INTC=5FIRPT=5FINTR 8
#define XPAR=5FSPI=5FEEPROM=5FIP2INTC=5FIRPT=5FMASK 0X000200
#define XPAR=5FOPB=5FINTC=5F0=5FSPI=5FEEPROM=5FIP2INTC=5FIRPT=5FINTR 9
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FIP2INTC=5FIRPT=5FMASK 0X000400
#define XPAR=5FOPB=5FINTC=5F0=5FDDR=5FSDRAM=5F32MX64=5FIP2INTC=5FIRPT=5FINTR 10
#define XPAR=5FRS232=5FUART=5FINTERRUPT=5FMASK 0X000800
#define XPAR=5FOPB=5FINTC=5F0=5FRS232=5FUART=5FINTERRUPT=5FINTR 11

/******************************************************************/

/* Definitions for driver DDR */
#define XPAR=5FXDDR=5FNUM=5FINSTANCES 1

/* Definitions for peripheral DDR=5FSDRAM=5F32MX64 */
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FECC=5FBASEADDR 0xFFFFFFFF
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FECC=5FHIGHADDR 0x00000000
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FDEVICE=5FID 0
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FINCLUDE=5FECC=5FINTR 0


/******************************************************************/

/* Definitions for peripheral DDR=5FSDRAM=5F32MX64 */
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FMEM0=5FBASEADDR 0x00000000
#define XPAR=5FDDR=5FSDRAM=5F32MX64=5FMEM0=5FHIGHADDR 0x0FFFFFFF

/******************************************************************/


/* Definitions for peripheral PLB=5FBRAM=5FIF=5FCNTLR=5F1 */
#define XPAR=5FPLB=5FBRAM=5FIF=5FCNTLR=5F1=5FBASEADDR 0xfffe0000
#define XPAR=5FPLB=5FBRAM=5FIF=5FCNTLR=5F1=5FHIGHADDR 0xffffffff


/******************************************************************/

#define XPAR=5FCPU=5FPPC405=5FCORE=5FCLOCK=5FFREQ=5FHZ 100000000

/******************************************************************/

#define XPAR=5FCPU=5FID 0
#define XPAR=5FPPC405=5FID 0
#define XPAR=5FPPC405=5FCORE=5FCLOCK=5FFREQ=5FHZ 100000000
#define XPAR=5FPPC405=5FISOCM=5FDCR=5FBASEADDR 0x00000010
#define XPAR=5FPPC405=5FISOCM=5FDCR=5FHIGHADDR 0x00000013
#define XPAR=5FPPC405=5FDSOCM=5FDCR=5FBASEADDR 0x00000020
#define XPAR=5FPPC405=5FDSOCM=5FDCR=5FHIGHADDR 0x00000023
#define XPAR=5FPPC405=5FDISABLE=5FOPERAND=5FFORWARDING 1
#define XPAR=5FPPC405=5FDETERMINISTIC=5FMULT 0
#define XPAR=5FPPC405=5FMMU=5FENABLE 1
#define XPAR=5FPPC405=5FDCR=5FRESYNC 0
#define XPAR=5FPPC405=5FHW=5FVER "2.00.c"

/******************************************************************/


/******************************************************************/

/* Cannonical Constant Names */

/******************************************************************/

#define XPAR=5FUARTLITE=5F0=5FBASEADDR XPAR=5FRS232=5FUART=5FBASEADDR
#define XPAR=5FUARTLITE=5F0=5FHIGHADDR XPAR=5FRS232=5FUART=5FHIGHADDR
#define XPAR=5FUARTLITE=5F0=5FDEVICE=5FID XPAR=5FRS232=5FUART=5FDEVICE=5FID

/******************************************************************/

#define XPAR=5FSPI=5F0=5FBASEADDR XPAR=5FSPI=5FEEPROM=5FBASEADDR
#define XPAR=5FSPI=5F0=5FHIGHADDR XPAR=5FSPI=5FEEPROM=5FHIGHADDR
#define XPAR=5FSPI=5F0=5FFIFO=5FEXIST XPAR=5FSPI=5FEEPROM=5FFIFO=5FEXIST
#define XPAR=5FSPI=5F0=5FSPI=5FSLAVE=5FONLY XPAR=5FSPI=5FEEPROM=5FSPI=5FSLAVE=5FONLY
#define XPAR=5FSPI=5F0=5FNUM=5FSS=5FBITS XPAR=5FSPI=5FEEPROM=5FNUM=5FSS=5FBITS
#define XPAR=5FSPI=5F0=5FDEVICE=5FID XPAR=5FSPI=5FEEPROM=5FDEVICE=5FID

/******************************************************************/

#define XPAR=5FSYSACE=5F0=5FBASEADDR XPAR=5FSYSACE=5FCOMPACTFLASH=5FBASEADDR
#define XPAR=5FSYSACE=5F0=5FHIGHADDR XPAR=5FSYSACE=5FCOMPACTFLASH=5FHIGHADDR
#define XPAR=5FSYSACE=5F0=5FDEVICE=5FID XPAR=5FSYSACE=5FCOMPACTFLASH=5FDEVICE=5FID

/******************************************************************/

#define XPAR=5FINTC=5F0=5FBASEADDR XPAR=5FOPB=5FINTC=5F0=5FBASEADDR
#define XPAR=5FINTC=5F0=5FHIGHADDR XPAR=5FOPB=5FINTC=5F0=5FHIGHADDR
#define XPAR=5FINTC=5F0=5FKIND=5FOF=5FINTR XPAR=5FOPB=5FINTC=5F0=5FKIND=5FOF=5FINTR
#define XPAR=5FINTC=5F0=5FDEVICE=5FID XPAR=5FOPB=5FINTC=5F0=5FDEVICE=5FID

/******************************************************************/

#define XPAR=5FINTC=5F0=5FSYSACE=5F0=5FVEC=5FID XPAR=5FOPB=5FINTC=5F0=5FSYSACE=5FCOMPACTFLASH=5FSY=
SACE=5FIRQ=5FINTR
#define XPAR=5FINTC=5F0=5FPCI=5F0=5FVEC=5FID=5FA XPAR=5FOPB=5FINTC=5F0=5FPCI32=5FBRIDGE=5FIP2INTC=5FIR=
PT=5FINTR
#define XPAR=5FINTC=5F0=5FPCI=5F0=5FVEC=5FID=5FB XPAR=5FOPB=5FINTC=5F0=5FPCI32=5FBRIDGE=5FIP2INTC=5FIR=
PT=5FINTR
#define XPAR=5FINTC=5F0=5FPCI=5F0=5FVEC=5FID=5FC XPAR=5FOPB=5FINTC=5F0=5FPCI32=5FBRIDGE=5FIP2INTC=5FIR=
PT=5FINTR
#define XPAR=5FINTC=5F0=5FPCI=5F0=5FVEC=5FID=5FD XPAR=5FOPB=5FINTC=5F0=5FPCI32=5FBRIDGE=5FIP2INTC=5FIR=
PT=5FINTR
#define XPAR=5FINTC=5F0=5FSPI=5F0=5FVEC=5FID XPAR=5FOPB=5FINTC=5F0=5FSPI=5FEEPROM=5FIP2INTC=5FIRPT=5FI=
NTR
#define XPAR=5FINTC=5F0=5FDDR=5F0=5FVEC=5FID XPAR=5FOPB=5FINTC=5F0=5FDDR=5FSDRAM=5F32MX64=5FIP2INTC=5F=
IRPT=5FINTR
#define XPAR=5FINTC=5F0=5FUARTLITE=5F0=5FVEC=5FID XPAR=5FOPB=5FINTC=5F0=5FRS232=5FUART=5FINTERRUPT=
=5FINTR

/******************************************************************/

#define XPAR=5FPLB=5FCLOCK=5FFREQ=5FHZ 100000000
#define XPAR=5FCORE=5FCLOCK=5FFREQ=5FHZ XPAR=5FCPU=5FPPC405=5FCORE=5FCLOCK=5FFREQ=5FHZ
#define XPAR=5FDDR=5F0=5FSIZE 0x10000000

/******************************************************************/

#define XPAR=5FPCI=5F0=5FCLOCK=5FFREQ=5FHZ    0

/******************************************************************/

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220

^ permalink raw reply

* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Liam Girdwood @ 2008-01-10 10:30 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801092141m5d4476d0l1c081307fd5c1969@mail.gmail.com>

On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote:

> ASOC v2 is sitting on a Wolfson server out of tree. I have been using
> it for several months without problem. The pace of it being merged
> could probably be sped up.

I think we are probably looking at submission in the next 8 - 10 weeks.
Currently most of the core code is complete, however some platforms and
codecs still need porting.

Liam

^ permalink raw reply

* Re: [RFC] add phy-handle property for fec_mpc52xx
From: Olaf Hering @ 2008-01-10 11:46 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, sven
In-Reply-To: <20080109163058.21643.30876.stgit@trillian.secretlab.ca>

On Wed, Jan 09, Grant Likely wrote:

> From: Olaf Hering <olaf@aepfle.de>
> 
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
> 
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
> 
> (Olaf's s-o-b line needs to go here)
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>


Signed-off-by: Olaf Hering <olaf@aepfle.de>

^ permalink raw reply

* Re: add phy-handle property for fec_mpc52xx
From: Olaf Hering @ 2008-01-10 11:47 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18309.33034.549240.640970@cargo.ozlabs.ibm.com>

On Thu, Jan 10, Paul Mackerras wrote:

> Olaf Hering writes:
> 
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
> >  	else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
> >  		of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
> >  		call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> > +#ifdef CONFIG_PPC_MPC52xx
> > +	} else if (strcmp(version, "EFIKA5K2") == 0) {
> 
> Why have you added this stuff in prom_find_mmu rather than putting it
> in fixup_device_tree_efika()?

I just looked for a "model" check.

^ permalink raw reply

* In PowerPC's feature, are there any difference between ML410 and ML403?
From: diak sim @ 2008-01-10 13:56 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

Hello everyone,

I am using ML410 to port a Linux 2.6 kernel, but init_IRQ() doesn't pass.
Porting Linux 2.6 to ML403 is successful? No such a problem?
In PowerPC's feature, are there any difference between ML410 and ML403?

Thanks.




      ___________________________________________________________ 
雅虎邮箱传递新年祝福,个性贺卡送亲朋! 
http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline

[-- Attachment #2: Type: text/html, Size: 623 bytes --]

^ permalink raw reply

* Re: How complete should the DTS be?
From: Josh Boyer @ 2008-01-10 13:58 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Sean MacLennan, David Gibson
In-Reply-To: <1199947849.6734.231.camel@pasglop>

On Thu, 10 Jan 2008 17:50:49 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote:
> > On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote:
> > > David Gibson wrote:
> > > > Hrm... I'd say this is not something which has a firm convention yet.
> > > > It's going to become more of an issue once we get a macros system for
> > > > dtc, so the "440EP" macro would have all the devices, even if some are
> > > > not connected on a given board.
> > > >
> > > > I'm contemplating suggesting that we adopt the "status" property from
> > > > IEEE1275 to cover this.
> > > >
> > > >   
> > > When I am laying out the dts, leaving out what isn't used makes the dts 
> > > file cleaner, at least in my view. It doesn't hurt to have the second 
> > > i2c bus there, but it also doesn't help and leaving it out points out 
> > > that it is not used.
> > > 
> > > When we get a macro system I assume the second i2c bus will be there but 
> > > hidden by a macro. It will still be clean and shouldn't cause grief.
> > 
> > Right, but if it is there we'll want to mark it as unused in some way
> > so that the kernel doesn't waste resources attempting to drive it.
> 
> Sure but I don't want to make it mandatory for people to put unused
> devices in. If the macro system brings them in, then yes, it's good to
> have a way to properly mark them unused. But people hand crafting DTS
> shouldn't have to bloat them.
> 
> There is -one- case where you may want to put unused devices, is if you
> do some kind of resource management on that specific bus (like need to
> be able to dynamically allocate space on the bus). In this case, you
> want to know everything that's there and potentially decodes addresses
> to avoid collisions.

There are other uses too.  E.g. pin sharing between devices based on
DIP switch settings.  You'd want to enumerate all the devices, and then
add 'status = "failed-not-connected"' to the ones that don't have pins.

josh

^ permalink raw reply

* Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jon Smirl @ 2008-01-10 14:14 UTC (permalink / raw)
  To: i2c, linuxppc-dev, Jean Delvare
In-Reply-To: <20071220044136.20091.70984.stgit@terra.home>

What is the review status of this series, should I post it again?

On 12/19/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Since copying i2c-mpc.c to maintain support for the ppc architecture seems to be an issue; instead rework i2c-mpc.c to use CONFIG_PPC_MERGE #ifdefs to support both the ppc and powerpc architecture. When ppc is deleted in six months these #ifdefs will need to be removed.
>
> Another rework of the i2c for powerpc device tree patch. This version implements standard alias naming only on the powerpc platform and only for the device tree names. The old naming mechanism of i2c_client.name,driver_name is left in place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in.
>
> The follow on patch to module-init-tools is also needed since the i2c subsystem has never implemented dynamic loading.
>
> The following series implements standard linux module aliasing for i2c modules on arch=powerpc. It then converts the mpc i2c driver from being a platform driver to an open firmware one. I2C device names are picked up from the device tree. Module aliasing is used to translate from device tree names into to linux kernel names. Several i2c drivers are updated to use the new aliasing.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [DTC PATCH 2/2] Preserve scanner state when /include/ing.
From: Jon Loeliger @ 2008-01-10 14:16 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080107202751.GB17782@ld0162-tx32.am.freescale.net>

So, like, the other day Scott Wood mumbled:
> This allows /include/s to work when in non-default states,
> such as PROPNODECHAR.
> 
> We may want to use state stacks to get rid of BEGIN_DEFAULT() altogether...
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>

Hmmm..  With this applied, I get the usual warning:

        CHK version_gen.h
         CC dtc-lexer.lex.o
    dtc-lexer.lex.c:1901: warning: 'yy_top_state' defined but not used

*grumble*

Applied.

jdl

^ permalink raw reply

* Re: [PATCH 2/3] Look for include files in the directory of the including file.
From: Jon Loeliger @ 2008-01-10 14:25 UTC (permalink / raw)
  To: David Gibson; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080110035201.GJ17816@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> > The doubly-linked list is intended to make it easier to construct search
> > path lists one-at-a-time from arguments in the proper order, without
> > needing to reverse the list at the end.
> 
> We've already got that problem with a bunch of the lists we create
> during parsing (we have several ugly add-to-end-of-singly-linked-list
> functions).  Going to doubly-linked lists might not be a bad idea, but
> we should do it across the board, probably using the kernel's list.h
> or something like it.

I would be happy to accept a kernel's-list.h-based refactoring
for doubly linked lists after the imminent 1.1 release!

jdl

^ permalink raw reply

* Re: [RFC 2/2] mpc52xx_psc_spi device driver must not touch port_config and cdm
From: Dragos Carp @ 2008-01-10 14:03 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080107190404.13535.65688.stgit@trillian.secretlab.ca>


Acked-by: Dragos Carp <dragos.carp@toptica.com>

On Mon, 2008-01-07 at 12:07 -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> 
> It is dangerous for an mpc52xx device driver to modify the port_config
> register.  If the driver is probed incorrectly, it will change the pin
> IO configuration in ways which may not be compatible with the board.
> port_config should be set up by the bootloader, or failing that, in
> the platform setup code in arch/powerpc/platforms/52xx.
> 
> Also, modifying CDM registers directly can cause a race condition with
> other drivers.  Instead call a common routine to modify CDM settings.
> 
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> 
>  drivers/spi/mpc52xx_psc_spi.c |   77 +----------------------------------------
>  1 files changed, 2 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
> index a3ebc63..253ed56 100644
> --- a/drivers/spi/mpc52xx_psc_spi.c
> +++ b/drivers/spi/mpc52xx_psc_spi.c
> @@ -330,80 +330,13 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device *spi)
>  
>  static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
>  {
> -	struct device_node *np;
> -	struct mpc52xx_cdm __iomem *cdm;
> -	struct mpc52xx_gpio __iomem *gpio;
>  	struct mpc52xx_psc __iomem *psc = mps->psc;
> -	u32 ul;
>  	u32 mclken_div;
>  	int ret = 0;
>  
> -#if defined(CONFIG_PPC_MERGE)
> -	np = of_find_compatible_node(NULL, NULL, "mpc5200-cdm");
> -	cdm = of_iomap(np, 0);
> -	of_node_put(np);
> -	np = of_find_compatible_node(NULL, NULL, "mpc5200-gpio");
> -	gpio = of_iomap(np, 0);
> -	of_node_put(np);
> -#else
> -	cdm = ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
> -	gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
> -#endif
> -	if (!cdm || !gpio) {
> -		printk(KERN_ERR "Error mapping CDM/GPIO\n");
> -		ret = -EFAULT;
> -		goto unmap_regs;
> -	}
> -
>  	/* default sysclk is 512MHz */
> -	mclken_div = 0x8000 |
> -		(((mps->sysclk ? mps->sysclk : 512000000) / MCLK) & 0x1FF);
> -
> -	switch (psc_id) {
> -	case 1:
> -		ul = in_be32(&gpio->port_config);
> -		ul &= 0xFFFFFFF8;
> -		ul |= 0x00000006;
> -		out_be32(&gpio->port_config, ul);
> -		out_be16(&cdm->mclken_div_psc1, mclken_div);
> -		ul = in_be32(&cdm->clk_enables);
> -		ul |= 0x00000020;
> -		out_be32(&cdm->clk_enables, ul);
> -		break;
> -	case 2:
> -		ul = in_be32(&gpio->port_config);
> -		ul &= 0xFFFFFF8F;
> -		ul |= 0x00000060;
> -		out_be32(&gpio->port_config, ul);
> -		out_be16(&cdm->mclken_div_psc2, mclken_div);
> -		ul = in_be32(&cdm->clk_enables);
> -		ul |= 0x00000040;
> -		out_be32(&cdm->clk_enables, ul);
> -		break;
> -	case 3:
> -		ul = in_be32(&gpio->port_config);
> -		ul &= 0xFFFFF0FF;
> -		ul |= 0x00000600;
> -		out_be32(&gpio->port_config, ul);
> -		out_be16(&cdm->mclken_div_psc3, mclken_div);
> -		ul = in_be32(&cdm->clk_enables);
> -		ul |= 0x00000080;
> -		out_be32(&cdm->clk_enables, ul);
> -		break;
> -	case 6:
> -		ul = in_be32(&gpio->port_config);
> -		ul &= 0xFF8FFFFF;
> -		ul |= 0x00700000;
> -		out_be32(&gpio->port_config, ul);
> -		out_be16(&cdm->mclken_div_psc6, mclken_div);
> -		ul = in_be32(&cdm->clk_enables);
> -		ul |= 0x00000010;
> -		out_be32(&cdm->clk_enables, ul);
> -		break;
> -	default:
> -		ret = -EINVAL;
> -		goto unmap_regs;
> -	}
> +	mclken_div = (mps->sysclk ? mps->sysclk : 512000000) / MCLK;
> +	mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
>  
>  	/* Reset the PSC into a known state */
>  	out_8(&psc->command, MPC52xx_PSC_RST_RX);
> @@ -427,12 +360,6 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
>  
>  	mps->bits_per_word = 8;
>  
> -unmap_regs:
> -	if (cdm)
> -		iounmap(cdm);
> -	if (gpio)
> -		iounmap(gpio);
> -
>  	return ret;
>  }
>  
> 
> 

^ permalink raw reply

* Re: Linux for ml310
From: Grant Likely @ 2008-01-10 14:54 UTC (permalink / raw)
  To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <525760687@web.de>

On 1/10/08, Joachim Meyer <Jogi95@web.de> wrote:
> Hi again
>
> I tried my compiled kernel this morning.
> I loaded my Bitstream onto the FPGA, then the zImage.elf via xmd: dow zIm=
age.elf.
> After I typed "run" I got foolowing message on an Terminal:
> ------------------------------------------------------------------------
> loaded at:     00400000 004F219C
> board data at: 004F0120 004F019C
> relocated to:  00404048 004040C4
> zimage at:     00404E39 004EF931
> avail ram:     004F3000 10000000
>
> Linux/PPC load: console=3DttyS0,9600
                          ^^^^^^^^^^
should be 'console=3DttyUL0'

> Uncompressing Linux...done.
> Now booting the kernel
>
> ------------------------------------------------------------------------
> Doesn't look that bad I think. ;)
> The Question I have is of course why he stops there.
> Is it why He can't find a rootfs?
> Or would he say this in that case.
> I found someone with an similar Problem:
> http://lists.ppckernel.org/pipermail/ppckernel/2006-May/000026.html
> but I already use the xparameters_ml310 from my BSP.
> Where must I look for the error?
> There where some warnings when I compiled the kernel. Is this ok?
>
> Greets & THX
> Joachim
>
> PS: My xparameters_ml310.h
> -------------------------------------------------------------------------=
-----------------------------------------------
> /*******************************************************************
> *
> * CAUTION: This file is automatically generated by libgen.
> * Version: Xilinx EDK 9.1.02 EDK_J_SP2.4
> * DO NOT EDIT.
> *
> * Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
> *
> * Description: Driver parameters
> *
> *******************************************************************/
>
> /* Definitions for driver UARTLITE */
> #define XPAR_XUARTLITE_NUM_INSTANCES 1
>
> /* Definitions for peripheral RS232_UART */
> #define XPAR_RS232_UART_BASEADDR 0x40600000
> #define XPAR_RS232_UART_HIGHADDR 0x4060FFFF
> #define XPAR_RS232_UART_DEVICE_ID 0
> #define XPAR_RS232_UART_BAUDRATE 9600
> #define XPAR_RS232_UART_USE_PARITY 0
> #define XPAR_RS232_UART_ODD_PARITY 0
> #define XPAR_RS232_UART_DATA_BITS 8
>
>
> /******************************************************************/
>
> /* Definitions for driver SPI */
> #define XPAR_XSPI_NUM_INSTANCES 1
>
> /* Definitions for peripheral SPI_EEPROM */
> #define XPAR_SPI_EEPROM_BASEADDR 0x4B308000
> #define XPAR_SPI_EEPROM_HIGHADDR 0x4B30807F
> #define XPAR_SPI_EEPROM_DEVICE_ID 0
> #define XPAR_SPI_EEPROM_FIFO_EXIST 1
> #define XPAR_SPI_EEPROM_SPI_SLAVE_ONLY 0
> #define XPAR_SPI_EEPROM_NUM_SS_BITS 1
>
>
> /******************************************************************/
>
> /* Definitions for driver PCI */
> #define XPAR_XPCI_NUM_INSTANCES 1
>
> /* Definitions for peripheral PCI32_BRIDGE */
> #define XPAR_PCI32_BRIDGE_DEVICE_ID 0
> #define XPAR_PCI32_BRIDGE_BASEADDR 0x42600000
> #define XPAR_PCI32_BRIDGE_HIGHADDR 0x4260FFFF
> #define XPAR_PCI32_BRIDGE_PCIBAR_0 0x00000000
> #define XPAR_PCI32_BRIDGE_PCIBAR_LEN_0 7
> #define XPAR_PCI32_BRIDGE_PCIBAR2IPIF_0 0
> #define XPAR_PCI32_BRIDGE_PCIBAR_ENDIAN_TRANSLATE_EN_0 0
> #define XPAR_PCI32_BRIDGE_PCI_PREFETCH_0 1
> #define XPAR_PCI32_BRIDGE_PCI_SPACETYPE_0 1
> #define XPAR_PCI32_BRIDGE_PCIBAR_1 0xffffffff
> #define XPAR_PCI32_BRIDGE_PCIBAR_LEN_1 20
> #define XPAR_PCI32_BRIDGE_PCIBAR2IPIF_1 0
> #define XPAR_PCI32_BRIDGE_PCIBAR_ENDIAN_TRANSLATE_EN_1 0
> #define XPAR_PCI32_BRIDGE_PCI_PREFETCH_1 1
> #define XPAR_PCI32_BRIDGE_PCI_SPACETYPE_1 1
> #define XPAR_PCI32_BRIDGE_PCIBAR_2 0xffffffff
> #define XPAR_PCI32_BRIDGE_PCIBAR_LEN_2 20
> #define XPAR_PCI32_BRIDGE_PCIBAR2IPIF_2 0
> #define XPAR_PCI32_BRIDGE_PCIBAR_ENDIAN_TRANSLATE_EN_2 0
> #define XPAR_PCI32_BRIDGE_PCI_PREFETCH_2 1
> #define XPAR_PCI32_BRIDGE_PCI_SPACETYPE_2 1
> #define XPAR_PCI32_BRIDGE_IPIFBAR_0 0x60000000
> #define XPAR_PCI32_BRIDGE_IPIF_HIGHADDR_0 0x7fffffff
> #define XPAR_PCI32_BRIDGE_IPIFBAR2PCI_0 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_ENDIAN_TRANSLATE_EN_0 0
> #define XPAR_PCI32_BRIDGE_IPIF_PREFETCH_0 1
> #define XPAR_PCI32_BRIDGE_IPIF_SPACETYPE_0 1
> #define XPAR_PCI32_BRIDGE_IPIFBAR_1 0x54000000
> #define XPAR_PCI32_BRIDGE_IPIF_HIGHADDR_1 0x57ffffff
> #define XPAR_PCI32_BRIDGE_IPIFBAR2PCI_1 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_ENDIAN_TRANSLATE_EN_1 0
> #define XPAR_PCI32_BRIDGE_IPIF_PREFETCH_1 1
> #define XPAR_PCI32_BRIDGE_IPIF_SPACETYPE_1 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_2 0xffffffff
> #define XPAR_PCI32_BRIDGE_IPIF_HIGHADDR_2 0x00000000
> #define XPAR_PCI32_BRIDGE_IPIFBAR2PCI_2 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_ENDIAN_TRANSLATE_EN_2 0
> #define XPAR_PCI32_BRIDGE_IPIF_PREFETCH_2 1
> #define XPAR_PCI32_BRIDGE_IPIF_SPACETYPE_2 1
> #define XPAR_PCI32_BRIDGE_IPIFBAR_3 0xffffffff
> #define XPAR_PCI32_BRIDGE_IPIF_HIGHADDR_3 0x00000000
> #define XPAR_PCI32_BRIDGE_IPIFBAR2PCI_3 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_ENDIAN_TRANSLATE_EN_3 0
> #define XPAR_PCI32_BRIDGE_IPIF_PREFETCH_3 1
> #define XPAR_PCI32_BRIDGE_IPIF_SPACETYPE_3 1
> #define XPAR_PCI32_BRIDGE_IPIFBAR_4 0xffffffff
> #define XPAR_PCI32_BRIDGE_IPIF_HIGHADDR_4 0x00000000
> #define XPAR_PCI32_BRIDGE_IPIFBAR2PCI_4 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_ENDIAN_TRANSLATE_EN_4 0
> #define XPAR_PCI32_BRIDGE_IPIF_PREFETCH_4 1
> #define XPAR_PCI32_BRIDGE_IPIF_SPACETYPE_4 1
> #define XPAR_PCI32_BRIDGE_IPIFBAR_5 0xffffffff
> #define XPAR_PCI32_BRIDGE_IPIF_HIGHADDR_5 0x00000000
> #define XPAR_PCI32_BRIDGE_IPIFBAR2PCI_5 0
> #define XPAR_PCI32_BRIDGE_IPIFBAR_ENDIAN_TRANSLATE_EN_5 0
> #define XPAR_PCI32_BRIDGE_IPIF_PREFETCH_5 1
> #define XPAR_PCI32_BRIDGE_IPIF_SPACETYPE_5 1
> #define XPAR_PCI32_BRIDGE_DMA_BASEADDR 0xFFFFFFFF
> #define XPAR_PCI32_BRIDGE_DMA_HIGHADDR 0x00000000
> #define XPAR_PCI32_BRIDGE_DMA_CHAN_TYPE 9
> #define XPAR_PCI32_BRIDGE_DMA_LENGTH_WIDTH 13
> #define XPAR_PCI32_BRIDGE_BRIDGE_IDSEL_ADDR_BIT 16
>
>
> /******************************************************************/
>
> #define XPAR_XSYSACE_MEM_WIDTH 8
> /* Definitions for driver SYSACE */
> #define XPAR_XSYSACE_NUM_INSTANCES 1
>
> /* Definitions for peripheral SYSACE_COMPACTFLASH */
> #define XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
> #define XPAR_SYSACE_COMPACTFLASH_HIGHADDR 0x4180FFFF
> #define XPAR_SYSACE_COMPACTFLASH_DEVICE_ID 0
> #define XPAR_SYSACE_COMPACTFLASH_MEM_WIDTH 8
>
>
> /******************************************************************/
>
> #define XPAR_INTC_MAX_NUM_INTR_INPUTS 12
> #define XPAR_XINTC_HAS_IPR 1
> #define XPAR_XINTC_USE_DCR 0
> /* Definitions for driver INTC */
> #define XPAR_XINTC_NUM_INSTANCES 1
>
> /* Definitions for peripheral OPB_INTC_0 */
> #define XPAR_OPB_INTC_0_BASEADDR 0x41200000
> #define XPAR_OPB_INTC_0_HIGHADDR 0x4120FFFF
> #define XPAR_OPB_INTC_0_DEVICE_ID 0
> #define XPAR_OPB_INTC_0_KIND_OF_INTR 0x00000C00
>
>
> /******************************************************************/
>
> #define XPAR_INTC_SINGLE_BASEADDR 0x41200000
> #define XPAR_INTC_SINGLE_HIGHADDR 0x4120FFFF
> #define XPAR_INTC_SINGLE_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_SBR_INT_MASK 0X000001
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_SBR_INT_INTR 0
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTF_MASK 0X000002
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTF_INTR 1
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTE_MASK 0X000004
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTE_INTR 2
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTD_MASK 0X000008
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTD_INTR 3
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTC_MASK 0X000010
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTC_INTR 4
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTB_MASK 0X000020
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTB_INTR 5
> #define XPAR_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTA_MASK 0X000040
> #define XPAR_OPB_INTC_0_SYSTEM_FPGA_0_PCI32_BRIDGE_PCI_INTA_INTR 6
> #define XPAR_SYSACE_COMPACTFLASH_SYSACE_IRQ_MASK 0X000080
> #define XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR 7
> #define XPAR_PCI32_BRIDGE_IP2INTC_IRPT_MASK 0X000100
> #define XPAR_OPB_INTC_0_PCI32_BRIDGE_IP2INTC_IRPT_INTR 8
> #define XPAR_SPI_EEPROM_IP2INTC_IRPT_MASK 0X000200
> #define XPAR_OPB_INTC_0_SPI_EEPROM_IP2INTC_IRPT_INTR 9
> #define XPAR_DDR_SDRAM_32MX64_IP2INTC_IRPT_MASK 0X000400
> #define XPAR_OPB_INTC_0_DDR_SDRAM_32MX64_IP2INTC_IRPT_INTR 10
> #define XPAR_RS232_UART_INTERRUPT_MASK 0X000800
> #define XPAR_OPB_INTC_0_RS232_UART_INTERRUPT_INTR 11
>
> /******************************************************************/
>
> /* Definitions for driver DDR */
> #define XPAR_XDDR_NUM_INSTANCES 1
>
> /* Definitions for peripheral DDR_SDRAM_32MX64 */
> #define XPAR_DDR_SDRAM_32MX64_ECC_BASEADDR 0xFFFFFFFF
> #define XPAR_DDR_SDRAM_32MX64_ECC_HIGHADDR 0x00000000
> #define XPAR_DDR_SDRAM_32MX64_DEVICE_ID 0
> #define XPAR_DDR_SDRAM_32MX64_INCLUDE_ECC_INTR 0
>
>
> /******************************************************************/
>
> /* Definitions for peripheral DDR_SDRAM_32MX64 */
> #define XPAR_DDR_SDRAM_32MX64_MEM0_BASEADDR 0x00000000
> #define XPAR_DDR_SDRAM_32MX64_MEM0_HIGHADDR 0x0FFFFFFF
>
> /******************************************************************/
>
>
> /* Definitions for peripheral PLB_BRAM_IF_CNTLR_1 */
> #define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xfffe0000
> #define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
>
>
> /******************************************************************/
>
> #define XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ 100000000
>
> /******************************************************************/
>
> #define XPAR_CPU_ID 0
> #define XPAR_PPC405_ID 0
> #define XPAR_PPC405_CORE_CLOCK_FREQ_HZ 100000000
> #define XPAR_PPC405_ISOCM_DCR_BASEADDR 0x00000010
> #define XPAR_PPC405_ISOCM_DCR_HIGHADDR 0x00000013
> #define XPAR_PPC405_DSOCM_DCR_BASEADDR 0x00000020
> #define XPAR_PPC405_DSOCM_DCR_HIGHADDR 0x00000023
> #define XPAR_PPC405_DISABLE_OPERAND_FORWARDING 1
> #define XPAR_PPC405_DETERMINISTIC_MULT 0
> #define XPAR_PPC405_MMU_ENABLE 1
> #define XPAR_PPC405_DCR_RESYNC 0
> #define XPAR_PPC405_HW_VER "2.00.c"
>
> /******************************************************************/
>
>
> /******************************************************************/
>
> /* Cannonical Constant Names */
>
> /******************************************************************/
>
> #define XPAR_UARTLITE_0_BASEADDR XPAR_RS232_UART_BASEADDR
> #define XPAR_UARTLITE_0_HIGHADDR XPAR_RS232_UART_HIGHADDR
> #define XPAR_UARTLITE_0_DEVICE_ID XPAR_RS232_UART_DEVICE_ID
>
> /******************************************************************/
>
> #define XPAR_SPI_0_BASEADDR XPAR_SPI_EEPROM_BASEADDR
> #define XPAR_SPI_0_HIGHADDR XPAR_SPI_EEPROM_HIGHADDR
> #define XPAR_SPI_0_FIFO_EXIST XPAR_SPI_EEPROM_FIFO_EXIST
> #define XPAR_SPI_0_SPI_SLAVE_ONLY XPAR_SPI_EEPROM_SPI_SLAVE_ONLY
> #define XPAR_SPI_0_NUM_SS_BITS XPAR_SPI_EEPROM_NUM_SS_BITS
> #define XPAR_SPI_0_DEVICE_ID XPAR_SPI_EEPROM_DEVICE_ID
>
> /******************************************************************/
>
> #define XPAR_SYSACE_0_BASEADDR XPAR_SYSACE_COMPACTFLASH_BASEADDR
> #define XPAR_SYSACE_0_HIGHADDR XPAR_SYSACE_COMPACTFLASH_HIGHADDR
> #define XPAR_SYSACE_0_DEVICE_ID XPAR_SYSACE_COMPACTFLASH_DEVICE_ID
>
> /******************************************************************/
>
> #define XPAR_INTC_0_BASEADDR XPAR_OPB_INTC_0_BASEADDR
> #define XPAR_INTC_0_HIGHADDR XPAR_OPB_INTC_0_HIGHADDR
> #define XPAR_INTC_0_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
> #define XPAR_INTC_0_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
>
> /******************************************************************/
>
> #define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_S=
YSACE_IRQ_INTR
> #define XPAR_INTC_0_PCI_0_VEC_ID_A XPAR_OPB_INTC_0_PCI32_BRIDGE_IP2INTC_I=
RPT_INTR
> #define XPAR_INTC_0_PCI_0_VEC_ID_B XPAR_OPB_INTC_0_PCI32_BRIDGE_IP2INTC_I=
RPT_INTR
> #define XPAR_INTC_0_PCI_0_VEC_ID_C XPAR_OPB_INTC_0_PCI32_BRIDGE_IP2INTC_I=
RPT_INTR
> #define XPAR_INTC_0_PCI_0_VEC_ID_D XPAR_OPB_INTC_0_PCI32_BRIDGE_IP2INTC_I=
RPT_INTR
> #define XPAR_INTC_0_SPI_0_VEC_ID XPAR_OPB_INTC_0_SPI_EEPROM_IP2INTC_IRPT_=
INTR
> #define XPAR_INTC_0_DDR_0_VEC_ID XPAR_OPB_INTC_0_DDR_SDRAM_32MX64_IP2INTC=
_IRPT_INTR
> #define XPAR_INTC_0_UARTLITE_0_VEC_ID XPAR_OPB_INTC_0_RS232_UART_INTERRUP=
T_INTR
>
> /******************************************************************/
>
> #define XPAR_PLB_CLOCK_FREQ_HZ 100000000
> #define XPAR_CORE_CLOCK_FREQ_HZ XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ
> #define XPAR_DDR_0_SIZE 0x10000000
>
> /******************************************************************/
>
> #define XPAR_PCI_0_CLOCK_FREQ_HZ    0
>
> /******************************************************************/
>
> _______________________________________________________________________
> Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
> kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=3D022220
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>


--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [PATCH V3] [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
From: Grant Likely @ 2008-01-10 15:01 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linuxppc-dev, dragos.carp
In-Reply-To: <20080110181316.1213f273.sfr@canb.auug.org.au>

On 1/10/08, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Grant,
>
> On Wed, 09 Jan 2008 22:26:30 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > +mpc52xx_map_common_devices(void)
> >  {
>
> > +     /* Clock Distribution Module, used by PSC clock setting function */
> > +     np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
>
> What happens if we find no node?

Both of_iomap and of_put fail gracefully if np is NULL.  IIRC that was
done on purpose so this exact thing could be done.

Users of mpc52xx_cdm (and the others done in this style) all check for
mpc52xx_cdm being NULL before dereferencing.

>
> > +     mpc52xx_cdm = of_iomap(np, 0);
> > +     of_node_put(np);
> >  }
>
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* DTC v1.1.0-rc1 tagged!
From: Jon Loeliger @ 2008-01-10 15:25 UTC (permalink / raw)
  To: linuxppc-dev

Folks,

I have tagged DTC v1.1.0-rc1 and pushed it out.

Please verify that this is going to be a viable 1.1 release!

Consider this the last call for features and first call
for bug fixes for the 1.1 release. :-)

Thanks,
jdl

^ permalink raw reply

* Platform matching style (was:: [RFC] add phy-handle property for fec_mpc52xx)
From: Grant Likely @ 2008-01-10 15:31 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, olaf, sven

On 1/9/08, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> As much as I despise having to work around firmware bugs, it looks
> indeed like this one has been broken for way too long to the point where
> users are being hurt, distros are being hurt, and telling people to
> whack things in nvramrc is just plain gross, so let's merge it.

Tangent question:

The Efika has device_type = "chrp" in the root node, but in Linux
Efika support does not use CHRP, it uses
arch/powerpc/platforms/52xx/efika.c.  However, if CHRP support is
compiled in then it will see the chrp device_type and bind to it
before efika.c has a chance to probe.  I see three reasonable
solutions to this:

1. Apply a device tree fixup to change device_type from "chrp" to
"efika" (the current solution)
2. Modify chrp_probe() to check specifically for the Efika when probing
3. Modify the link order so that Efika is probed before CHRP.

All three of these solutions will work, but I'd like to get opinions
on which is stylistically the best approach (or if there is another
approach I'm missing).

In general, I'm trying to reduce the Efika fixups down to only what is
absolutely necessary and as much as possible work with the provided
device tree.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Timur Tabi @ 2008-01-10 15:39 UTC (permalink / raw)
  To: Jon Smirl, david, Grant Likely, Olof Johansson
  Cc: linuxppc-dev, alsa-devel, Liam Girdwood
In-Reply-To: <1199961015.19903.270.camel@localhost.localdomain>

Liam Girdwood wrote:

> I think we are probably looking at submission in the next 8 - 10 weeks.
> Currently most of the core code is complete, however some platforms and
> codecs still need porting.

With that in mind, can I get some kind of consensus from the PPC side as to 
whether this ASoC V1 driver is okay?  I want to get it into 2.6.25.

Keep in mind:

1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 
PowerPC driver "100% correct".

2) The CS4270 driver does not support I2C nodes in the device tree, so there's 
not point in adding any to the 8610 DTS.

3) Liam and I are working on porting this driver to ASoC V2 and resolving all 
open PPC issue, but that won't be done in time for 2.6.25.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: Platform matching style (was:: [RFC] add phy-handle property for fec_mpc52xx)
From: Olof Johansson @ 2008-01-10 15:52 UTC (permalink / raw)
  To: Grant Likely; +Cc: olaf, sven, linuxppc-dev
In-Reply-To: <fa686aa40801100731k62b004ecq4f6058aea5df9da0@mail.gmail.com>

On Thu, Jan 10, 2008 at 08:31:18AM -0700, Grant Likely wrote:

> 1. Apply a device tree fixup to change device_type from "chrp" to
> "efika" (the current solution)
> 2. Modify chrp_probe() to check specifically for the Efika when probing
> 3. Modify the link order so that Efika is probed before CHRP.
>
> All three of these solutions will work, but I'd like to get opinions
> on which is stylistically the best approach (or if there is another
> approach I'm missing).
> 
> In general, I'm trying to reduce the Efika fixups down to only what is
> absolutely necessary and as much as possible work with the provided
> device tree.

(3) sounds fragile to me.

There's already code in the kernel that does (2): pSeries_probe checks
to make sure it's not running on a cell blade. That has the benefit of
presenting something closer to the real device tree to the user through
/proc/device-tree, not that I'm sure it has all that much value.


-Olof

^ permalink raw reply

* Re: Linux for ml310
From: Joachim Meyer @ 2008-01-10 15:44 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-embedded

Big thx...it works
Greez
Joachim
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

^ permalink raw reply

* Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHY layerfunctionality
From: Anton Vorontsov @ 2008-01-10 15:53 UTC (permalink / raw)
  To: Paul Mackerras, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <003c01c84a3e$15d3a9c0$02ac10ac@Jocke>

On Sat, Dec 29, 2007 at 06:13:08PM +0100, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: 
> > linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozlabs.org 
> > [mailto:linuxppc-dev-bounces+joakim.tjernlund=transmode.se@ozl
> > abs.org] On Behalf Of Vitaly Bordug
> > Sent: den 6 december 2007 23:51
> > To: Paul Mackerras
> > Cc: netdev@vger.kernel.org; linuxppc-dev
> > Subject: [PATCH 1/3] [NET] phy/fixed.c: rework to not 
> > duplicate PHY layerfunctionality
> > 
> > 
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> > 
> > As an additional bonus, now there is no need to register MDIO bus
> > for each PHY, all emulated PHYs placed on the platform fixed MDIO bus.
> > There is also no more need to pre-allocate PHYs via .config option,
> > this is all now handled dynamically.
> > 
> > 
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Acked-by: Jeff Garzik <jeff@garzik.org>
> 
> What happened to this patch set? Is it sitting in a tree somewhere waiting
> for 2.4.25 or does it need more work?
        ^ we're too late then. ;-)

Patches already began to fuzz at the fsl_soc.c, yet more time and
they'll reject to apply. So.. Paul, Kumar can we get this in for
2.6.25?

I believe afterward this one will need some attention too:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048473.html

Thanks in advance,


p.s. I just noticed that "fsl_soc: add support for gianfar for
fixed-link .." patch could be cosmetically improved (removing
casts, adding checks for size after the of_get_property), but I
hope we can do this on top of already applied patches.

Thanks again,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

^ permalink raw reply

* Re: Toolchain for Freescale e200
From: Kumar Gala @ 2008-01-10 15:46 UTC (permalink / raw)
  To: Per-Erik Johansson; +Cc: linuxppc-embedded
In-Reply-To: <1526.213.15.68.47.1199872028.squirrel@webmail.chalmers.se>


On Jan 9, 2008, at 3:47 AM, Per-Erik Johansson wrote:

> Hi
>
> I need a new toolchain since my old one hasn't got support for the  
> (as)
> -me200 and book-e stuff I need to compile a kernel for the e200 core.
> What flags do I specify to get what I need?
> --target=powerpc-e200-linux-gnu --with-cpu=?? --enable-threads=posix
> --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
> And should I use a particular version of gcc, binutils..?
>
> I'm not that familiar with building cross-toolchains, have tried with
> tools like crosstool and buildroot but cant seem to get it to build  
> what I
> need.
>> From what I understand the e200 and e500 are code compatible so  
>> maybe I
> could a toolchain for e500 instead, --with-cpu=8540?
> Any help is much appreciated!

if you aren't using VLE than an e500 toolchain should be sufficient.

- k

^ permalink raw reply

* Re: Linux for ml310
From: Grant Likely @ 2008-01-10 15:48 UTC (permalink / raw)
  To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <526334208@web.de>

On 1/10/08, Joachim Meyer <Jogi95@web.de> wrote:
> Big thx...it works

Congratulations!  Have fun.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

^ permalink raw reply

* 2.6.22-ppc8xx fec.c bugs
From: raul.moreno @ 2008-01-10 15:57 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <OF9B97E7E0.352B883F-ONC12573CA.0058283E-C12573CA.005AFC5C@abengoa.com>

Hello everyone,

I don't know who the maintainer of the FEC (Fast Ethernet Controller) i=
n
the ppc8xx achitecture is, so I am writing this email here.

After spending some time working withy kernel 2.6.15 for the ppc8xx
architecture, I've recently started to port to the 2.6.22. Doing so I h=
ave
found some bugs in the code managing the FEC (fec.c).

First I found (and cleared) some compilation errors due to inconsistent=

changes in function prototypes (i.e. INIT_WORK). Moreover, if the "MDIO=
 for
PHY" configuration is used (in my case for an LXT971 fec) the kernel
couldn't manage to finish booting and was caught in an infinite loop
waiting for fec intialization.

I've seen that some bugs were fixed in the latest kernel but others hav=
en't
been addressed (possibly undetected yet). The following is a diff with
corrections I made to the 2.6.22 'fec.c' file (currently seems to work
fine).

883a884

> #ifdef PHY_INTERRUPT

884a886,888

> #else

>     fep->link =3D 1;    /* If PHY_INTERRUPT is not defined, fep->link=
  must
be also put to 1 */

> #endif

1077c1082

< #endif /* CONFIG_FEC_LXT970 */

---

> #endif /* CONFIG_FEC_LXT971 */

1281c1286

<           container_of(work, struct fec_enet_private, phy_task);

---

>           container_of(work, struct fec_enet_private, phy_task2);
/* use phy_task2 -->config */

1660c1665,1666

<     cbd_base =3D (cbd_t *)dma_alloc_coherent(dev->class_dev.dev, PAGE=
_SIZE,

---

>     /* The first parameter has changed */

>     cbd_base =3D (cbd_t *)dma_alloc_coherent(&dev->dev, PAGE_SIZE,

1676,1678c1682,1684

<           ba =3D (unsigned char *)dma_alloc_coherent(dev->class_dev.d=
ev,

---

>           /* The first parameter has changed */

>           ba =3D (unsigned char *)dma_alloc_coherent(&dev->dev,

1814,1816c1821,1824

< #ifdef    CONFIG_USE_MDIO

<     INIT_WORK(&fep->phy_task, mii_relink, (void *)dev);

<     INIT_WORK(&fep->phy_task2, mii_display_config, (void *)dev);

---

> #ifdef    CONFIG_USE_MDIO         /* INIT_WORK has only two parameter=

since 2.6.20 */

>     INIT_WORK(&fep->phy_task, mii_relink);

>     INIT_WORK(&fep->phy_task2, mii_display_config);



I hope this helps.
Best regards,

Ra=FAl Moreno=

^ 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