* does Gianfar Ethernet Controller Version 1.1 support MARVELL 88E1111?
From: 郭 剑非 @ 2006-06-08 7:43 UTC (permalink / raw)
To: Linuxppc-embedded
Hi all,
I'm debugging my board with MPC 8540 and marvell 88e1111 designed on it.
I'm sure the hardware connection is correct, and the phy's ID could be read
through terminal port. But anyway, phy can not work. I wonder if it is the
driver's problem? Since the Gianfar Ethernet Controller Version 1.1
surpport 88e1011s, but some 88e1111's registers are different from
88e1011s'. Actually I'm a new guy to Linux. Has anybody ever used 88e1111
phy in Linux envirenmemt? Please
give me some points. Thank you!
I have read the Gianfar ethernet controller driver, but it's difficult for
me to find out the sofware flow.
^ permalink raw reply
* RE: does Gianfar Ethernet Controller Version 1.1 support MARVELL 88E1111?
From: Liu Dave-r63238 @ 2006-06-08 8:41 UTC (permalink / raw)
To: '郭 剑非', Linuxppc-embedded
> Hi all,
> I'm debugging my board with MPC 8540 and marvell 88e1111
> designed on it.
> I'm sure the hardware connection is correct, and the phy's ID
> could be read
> through terminal port. But anyway, phy can not work. I wonder
Are you sure the hardware is no problem?
Can you successfully tftp files with the port in u-boot?
What is the phy interface mode you used?
> if it is the
> driver's problem? Since the Gianfar Ethernet Controller Version 1.1
> surpport 88e1011s, but some 88e1111's registers are different from
> 88e1011s'. Actually I'm a new guy to Linux. Has anybody ever
> used 88e1111
> phy in Linux envirenmemt? Please
Basically, the 88e1111 is same 88e1011s.
> give me some points. Thank you!
> I have read the Gianfar ethernet controller driver, but it's
> difficult for
> me to find out the sofware flow.
>
Change the board-specific things, for example
PHY address, PHY interrupt.
Please reference /arch/ppc/platforms/85xx/mpc8540_ads.c
-Dave
^ permalink raw reply
* (no subject)
From: huseyin_yeter1977 @ 2006-06-08 8:57 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 9 bytes --]
thank you
[-- Attachment #2: Type: text/html, Size: 47 bytes --]
^ permalink raw reply
* a problem of kernel-module version mismatch.
From: Ming Liu @ 2006-06-08 13:27 UTC (permalink / raw)
To: Linuxppc-embedded
Hello everyone,
Now I am trying to cross-compile the driver for a customed FIFO peripheral
in my design. My embedded platform is Xilinx ML403 development board
(Virtex4) and the host linux is suse 64-bit. I use the cross-compiler to
compile the driver source files provided by Xilinx EDK. But the problem
happens:
# insmod FIFO.o
insmod: kernel-module version mismatch
FIFO.o was compiled for kernel version
while this kernel is version 2.4.26
If I use "-f" option, it shows:
insmod: kernel-module version mismatch
FIFO.o was compiled for kernel version
while this kernel is version 2.4.26
insmod: unresolved symbol XIo_In32
insmod: unresolved symbol XIO_Out32
My embedded linux kernel version is 2.4.26. My compiler is
"powerpc-405-linux-gnu-gcc 3.4.1". I don't know how the version mismatch
happened. Shall I change another cross-compiler version? I will appreciate
a lot if someone could tell me how to solve it. Thanks a lot.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: a problem of kernel-module version mismatch.
From: Arnd Bergmann @ 2006-06-08 13:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY110-F1B771BD82DFE542552C0BB28B0@phx.gbl>
On Thursday 08 June 2006 15:27, Ming Liu wrote:
> My embedded linux kernel version is 2.4.26. My compiler is
> "powerpc-405-linux-gnu-gcc 3.4.1". I don't know how the version mismatch
> happened. Shall I change another cross-compiler version? I will appreciate
> a lot if someone could tell me how to solve it. Thanks a lot.
The easiest way is usually to put the driver in your source tree
and compile everything together. That also makes it easier to
distribute the complete source tree to your users.
> insmod: unresolved symbol XIo_In32
> insmod: unresolved symbol XIO_Out32
that looks like part of your module is missing. Try to find where thses
functions are defined in there and why that isn't compiled.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/10] Add the mpc8641 hpcn Kconfig and Makefiles.
From: Jon Loeliger @ 2006-06-08 13:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <0EC9507F-27EE-46E4-A92A-E4150A2FA312@kernel.crashing.org>
On Wed, 2006-06-07 at 23:44, Kumar Gala wrote:
> On Jun 7, 2006, at 5:34 PM, Jon Loeliger wrote:
> > config PPC_I8259
> > bool
> > + default y if PPC_86xx
> > default n
>
> This dependancy seems too generic, shouldn't it be based on some
> board (its not like 86xx actually has an i8259 in it).
> > +# Makefile for the PowerPC 86xx linux kernel.
> > +#
> > +
> > +obj-$(CONFIG_PPC_86xx) += mpc86xx_hpcn.o misc.o
>
> Seems like mpc86xx_hpcn.o is board specific code and should move down
> one line.
> > +
> > +config I8259_LEVEL_TRIGGER
> > + bool
> > + depends on MPC8641
> > + default y
>
> again, seems like it should depend on a board & not MPC8641
OK, I'll fix all of those.
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index d6d4494..fbeae82 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -252,12 +252,12 @@ config I2C_POWERMAC
> >
> should probably separate this out into its own patch for the I2C
> maintainer.
Ah, OK. Who is that then?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 7/10] Add use of mpc86xx.h include files in legacy header files.
From: Jon Loeliger @ 2006-06-08 13:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <542A1CA4-6A5A-41DA-98D2-C61D5376B761@kernel.crashing.org>
On Wed, 2006-06-07 at 23:49, Kumar Gala wrote:
> On Jun 7, 2006, at 5:42 PM, Jon Loeliger wrote:
>
> >
> > Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >
> > ---
> >
> > include/asm-ppc/io.h | 2 ++
> > include/asm-ppc/ppc_sys.h | 2 ++
> > include/asm-ppc/serial.h | 2 ++
> > 3 files changed, 6 insertions(+), 0 deletions(-)
>
> Are the io.h & serial.h really needed for ARCH=powerpc? What does
> serial.h get from asm/mpc86xx.h? I can see the possibility of io.h
> needing some stuff from asm/mpc86xx.h
I'll check and do a round of include scrubbing.
There was some silliness going on there earlier,
but it could have been cleaned up along the way too.
> > index 40f197a..4eaf80d 100644
> > --- a/include/asm-ppc/ppc_sys.h
> > +++ b/include/asm-ppc/ppc_sys.h
> > @@ -27,6 +27,8 @@ #elif defined(CONFIG_83xx)
> > #include <asm/mpc83xx.h>
> > #elif defined(CONFIG_85xx)
> > #include <asm/mpc85xx.h>
> > +#elif defined(CONFIG_PPC_86xx)
> > +#include <asm/mpc86xx.h>
>
> this should go since I can't imagine your using ppc_sys.
Right. Leftover cleaning tidbits. It's gone.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 6/10] Add 8641 Register space and IRQ definitions.
From: Jon Loeliger @ 2006-06-08 13:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <EDB92A0C-28BA-4E18-98ED-F37C1EEDF8C2@kernel.crashing.org>
On Wed, 2006-06-07 at 23:57, Kumar Gala wrote:
> > +/* Offset from CCSRBAR */
> > +#define MPC86xx_DMA_OFFSET (0x21000)
> > +#define MPC86xx_DMA_SIZE (0x01000)
> > +#define MPC86xx_DMA0_OFFSET (0x21100)
> > +#define MPC86xx_DMA0_SIZE (0x00080)
> > +#define MPC86xx_DMA1_OFFSET (0x21180)
> > +#define MPC86xx_DMA1_SIZE (0x00080)
> > +#define MPC86xx_DMA2_OFFSET (0x21200)
> > +#define MPC86xx_DMA2_SIZE (0x00080)
> > +#define MPC86xx_DMA3_OFFSET (0x21280)
> > +#define MPC86xx_DMA3_SIZE (0x00080)
> > +
> > +#define MPC86xx_GUTS_OFFSET (0xe0000)
> > +#define MPC86xx_GUTS_SIZE (0x01000)
> > +
> > +#define MPC86xx_OPENPIC_OFFSET (0x40000)
> > +#define MPC86xx_OPENPIC_SIZE (0x40000)
> > +#define MPC86xx_PEX1_OFFSET (0x08000)
> > +#define MPC86xx_PEX1_SIZE (0x01000)
> > +#define MPC86xx_PEX2_OFFSET (0x09000)
> > +#define MPC86xx_PEX2_SIZE (0x01000)
> > +#define MPC86xx_PERFMON_OFFSET (0xe1000)
> > +#define MPC86xx_PERFMON_SIZE (0x01000)
> > +#define MPC86xx_UART0_OFFSET (0x04500)
> > +#define MPC86xx_UART0_SIZE (0x00100)
> > +#define MPC86xx_UART1_OFFSET (0x04600)
> > +#define MPC86xx_UART1_SIZE (0x00100)
> > +#define MPC86xx_MCM_OFFSET (0x00000)
> > +#define MPC86xx_MCM_SIZE (0x02000)
> > +
> > +#define MPC86xx_CCSRBAR_SIZE (1024*1024)
>
> Let's kill any OFFSET & SIZEs that aren't actually needed in code. I
> would hope most of these are going from the flat dev tree.
OK. I'll trim this set down.
> > +enum ppc_sys_devices {
> > + MPC86xx_TSEC1,
> > + MPC86xx_TSEC2,
> > + MPC86xx_TSEC3,
> > + MPC86xx_TSEC4,
> > + MPC86xx_DUART,
> > + MPC86xx_MDIO,
> > + MPC86xx_IIC1,
> > + MPC86xx_IIC2,
> > + NUM_PPC_SYS_DEVS,
> > +};
>
> please kill, I can't imagine any code actually using this.
Yep. Again, leftover tidbits. I'll fix it.
> > +#define PVR_8641 0x80040000
>
> Does anything code use this define, if not let's kill it. I think we
> are trying to reduce such things.
I'll check and remove as possible!
Thanks,
jdl
^ permalink raw reply
* Re: a problem of kernel-module version mismatch.
From: Ming Liu @ 2006-06-08 13:52 UTC (permalink / raw)
To: arnd.bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200606081536.15145.arnd.bergmann@de.ibm.com>
Thanks for your telling first.
>The easiest way is usually to put the driver in your source tree
>and compile everything together. That also makes it easier to
>distribute the complete source tree to your users.
Sorry that I am a novice in Linux. I don't know how can I put the driver in
my source tree and compile everything together. It looks like that there is
no option in the menuconfig to choose a specially customed peripheral. So I
think I only can include the customed peripheral as a module. Could you
please say in a detail on how to do that?
> > insmod: unresolved symbol XIo_In32
> > insmod: unresolved symbol XIO_Out32
>
>that looks like part of your module is missing. Try to find where thses
>functions are defined in there and why that isn't compiled.
It's very strange because I have checked the source. In the header file of
xio.h, there are the following sentences,
/************************** Function Prototypes
******************************/
/* The following functions allow the software to be transportable across
* processors which may use memory mapped I/O or I/O which is mapped into a
* seperate address space such as X86. The functions are better suited for
* debugging and are therefore the default implementation. Macros can
instead
* be used if USE_IO_MACROS is defined.
*/
#ifndef USE_IO_MACROS
/* Functions */
Xuint8 XIo_In8(XIo_Address InAddress);
Xuint16 XIo_In16(XIo_Address InAddress);
Xuint32 XIo_In32(XIo_Address InAddress);
void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
#else
/* The following macros allow optimized I/O operations for memory mapped
I/O
* Note that the SYNCHRONIZE_IO may be moved by the compiler during
* optimization.
*/
#define XIo_In8(InputPtr) (*(volatile Xuint8 *)(InputPtr));
SYNCHRONIZE_IO;
#define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));
SYNCHRONIZE_IO;
#define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));
SYNCHRONIZE_IO;
#define XIo_Out8(OutputPtr, Value) \
{ (*(volatile Xuint8 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
#define XIo_Out16(OutputPtr, Value) \
{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
#define XIo_Out32(OutputPtr, Value) \
{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
#endif
I think these are the defination of XIo_In32 and XIo_Out32. Also, during
the compilation, there is no error to complain that "XIo_In32 or XIo_Out32
undeclared".
More suggestions are appreciated. Thanks.
BR
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* A Couple of 2.6/Xilinx Questions
From: rakirtley @ 2006-06-08 14:45 UTC (permalink / raw)
To: linuxppc-embedded
All,
I've been attempting to get a 2.6 version running on the Xilinx ML403 and only really need the ethernet and compact flash devices at this point. I've tried versions from mvista, kernel.org, etc; all only have the serial8250 device enabled. Obviously adding devices is a lot of work and it appears that you all have already made great progress enabling ethernet.
Are any of the advanced versions upon which you all work generally available? If so could you please provide a location? Apologies in advance for polluting your emailboxes and thanks in advance for any help/pointers that you can provide. I'll be more than happy to share any mods that I make (if any)
Rance Kirtley
Applied Systems Intelligence
Roswell, GA USA
^ permalink raw reply
* Re: a problem of kernel-module version mismatch.
From: Arnd Bergmann @ 2006-06-08 15:25 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F11CA5067CA16CB9E95E997B28B0@phx.gbl>
On Thursday 08 June 2006 15:52, Ming Liu wrote:
> >The easiest way is usually to put the driver in your source tree
> >and compile everything together. That also makes it easier to
> >distribute the complete source tree to your users.
>=20
> Sorry that I am a novice in Linux. I don't know how can I put the driver =
in=20
> my source tree and compile everything together. It looks like that there =
is=20
> no option in the menuconfig to choose a specially customed peripheral. So=
I=20
> think I only can include the customed peripheral as a module. Could you=20
> please say in a detail on how to do that?=20
The most simple way would be to put it into linux/drivers/misc and add it
to the Makefile in there.
> > > insmod: unresolved symbol XIo_In32
> > > insmod: unresolved symbol XIO_Out32
> >
> >that looks like part of your module is missing. Try to find where thses
> >functions are defined in there and why that isn't compiled.
>=20
> It's very strange because I have checked the source. In the header file o=
f=20
> xio.h, there are the following sentences,
>=20
> /************************** Function Prototypes=20
> ******************************/
>=20
> /* The following functions allow the software to be transportable across
> =A0* processors which may use memory mapped I/O or I/O which is mapped in=
to a
> =A0* seperate address space such as X86. =A0The functions are better suit=
ed for
> =A0* debugging and are therefore the default implementation. Macros can=20
> instead
> =A0* be used if USE_IO_MACROS is defined.
> =A0*/
> #ifndef USE_IO_MACROS
The comment tells you that you either need to implement these functions
youself or #define USE_IO_MACROS in the code before this.
> /* Functions */
> Xuint8 XIo_In8(XIo_Address InAddress);
> Xuint16 XIo_In16(XIo_Address InAddress);
> Xuint32 XIo_In32(XIo_Address InAddress);
>=20
> void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
>=20
> #else
>=20
> /* The following macros allow optimized I/O operations for memory mapped=
=20
> I/O
> =A0* Note that the SYNCHRONIZE_IO may be moved by the compiler during
> =A0* optimization.
> =A0*/
>=20
> #define XIo_In8(InputPtr) =A0(*(volatile Xuint8 =A0*)(InputPtr));=20
> SYNCHRONIZE_IO;
> #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));=20
> SYNCHRONIZE_IO;
> #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));=20
> SYNCHRONIZE_IO;
>=20
> #define XIo_Out8(OutputPtr, Value) =A0\
> =A0 =A0 { (*(volatile Xuint8 =A0*)(OutputPtr) =3D Value); SYNCHRONIZE_IO;=
}
> #define XIo_Out16(OutputPtr, Value) \
> =A0 =A0 { (*(volatile Xuint16 *)(OutputPtr) =3D Value); SYNCHRONIZE_IO; }
> #define XIo_Out32(OutputPtr, Value) \
> =A0 =A0 { (*(volatile Xuint32 *)(OutputPtr) =3D Value); SYNCHRONIZE_IO; }
>=20
> #endif
These macros are probably broken on powerpc.
>=20
> I think these are the defination of XIo_In32 and XIo_Out32. Also, during=
=20
> the compilation, there is no error to complain that "XIo_In32 or XIo_Out3=
2=20
> undeclared".=20
>=20
I would suggest you remove that part of the header file completely, and
replace it with:
#define XIo_In32(p) in_le32(x)
#define XIO_Out32(p,v) out_le32(p, v)
Arnd <><
^ permalink raw reply
* RE: Making Two ethernet interfaces up in Linux
From: Rick Moleres @ 2006-06-08 15:30 UTC (permalink / raw)
To: Shantanu Nalage, Antonio Di Bacco, linuxppc-embedded
Shantanu,
Can you post the xemac_g.c file in the xilinx_enet directory? Also,
which version of the EDK are you using? There was a bug in EDK 7.x that
prevented multiple Ethernet interfaces from working properly.
It would also be helpful to see xparameters_ml300.h from the
arch/ppc/platforms/xilinx_ocp directory.
Thanks,
-Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of Shantanu Nalage
Sent: Wednesday, June 07, 2006 11:16 PM
To: Antonio Di Bacco; linuxppc-embedded@ozlabs.org
Subject: Re: Making Two ethernet interfaces up in Linux
Thanks for the reply.
The driver which we are using for the ethernet is provided by Xilinx.
In the Linux kernel source, it is located in net/xilinx_enet
directory. We are attaching the adapter file for the driver provided
by Xilinx for the ethernet.
When we gave a first try, it showed two ethernet interfaces eth0 and
eth1 as an output of ifconfig command but only eth0 works, when eth1
is disabled. When both interfaces are up, neither interface works.
While even when eth0 is disabled, eth1 interface doesn't work.
With regards,
Shantanu.
On 6/4/06, Antonio Di Bacco <antonio.dibacco@aruba.it> wrote:
> > We are trying to port Linux on Xilinx Board XUPV2Pro which
is
> > similar in most aspects to the Xilinx ML300 board. Linux is up and
> > running for the original board i.e. having only one ethrnet
interface.
> > Now since we wanted to have the board working as router, we designed
a
> > daughter board with two ethernet phy interfaces. The MACs required
for
> > that are instantiated in Xilinx ....
>
> You have already the driver for the first MAC, then you should start
from that
> modifying the init procedure for example and all the others. Your
driver
> should initialize both the MACs and also create two devices calling
> init_etherdev tow times. If you post your driver I can suggest what to
> change. It is not so difficult.
>
> Bye,
> Antonio.
>
>
^ permalink raw reply
* Re: a problem of kernel-module version mismatch.
From: Ming Liu @ 2006-06-08 15:54 UTC (permalink / raw)
To: arnd.bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200606081725.37621.arnd.bergmann@de.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 4010 bytes --]
Dear Arnd,
Thanks a lot for your help. Now I have solved the problem of version
mismatch. The reason is I haven't include the sentence of "#define MODULE".
However the problem of unresolved symbol XIo_In32 and XIo_Out32 still
exists. I will try to solve it following your suggestion. If any question,
I will ask you again. Thanks a lot for your help.
Regards
Ming
>From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>To: "Ming Liu" <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: a problem of kernel-module version mismatch.
>Date: Thu, 8 Jun 2006 17:25:37 +0200
>
>On Thursday 08 June 2006 15:52, Ming Liu wrote:
> > >The easiest way is usually to put the driver in your source tree
> > >and compile everything together. That also makes it easier to
> > >distribute the complete source tree to your users.
> >
> > Sorry that I am a novice in Linux. I don't know how can I put the
driver in
> > my source tree and compile everything together. It looks like that
there is
> > no option in the menuconfig to choose a specially customed peripheral.
So I
> > think I only can include the customed peripheral as a module. Could you
> > please say in a detail on how to do that?
>
>The most simple way would be to put it into linux/drivers/misc and add it
>to the Makefile in there.
>
> > > > insmod: unresolved symbol XIo_In32
> > > > insmod: unresolved symbol XIO_Out32
> > >
> > >that looks like part of your module is missing. Try to find where
thses
> > >functions are defined in there and why that isn't compiled.
> >
> > It's very strange because I have checked the source. In the header file
of
> > xio.h, there are the following sentences,
> >
> > /************************** Function Prototypes
> > ******************************/
> >
> > /* The following functions allow the software to be transportable
across
> > ? processors which may use memory mapped I/O or I/O which is mapped
into a
> > ? seperate address space such as X86. The functions are better suited
for
> > ? debugging and are therefore the default implementation. Macros can
> > instead
> > ? be used if USE_IO_MACROS is defined.
> > ?/
> > #ifndef USE_IO_MACROS
>
>The comment tells you that you either need to implement these functions
>youself or #define USE_IO_MACROS in the code before this.
>
> > /* Functions */
> > Xuint8 XIo_In8(XIo_Address InAddress);
> > Xuint16 XIo_In16(XIo_Address InAddress);
> > Xuint32 XIo_In32(XIo_Address InAddress);
> >
> > void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> > void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> > void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
> >
> > #else
> >
> > /* The following macros allow optimized I/O operations for memory
mapped
> > I/O
> > ? Note that the SYNCHRONIZE_IO may be moved by the compiler during
> > ? optimization.
> > ?/
> >
> > #define XIo_In8(InputPtr) ?*(volatile Xuint8 ?)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));
> > SYNCHRONIZE_IO;
> >
> > #define XIo_Out8(OutputPtr, Value) \
> > ??{ (*(volatile Xuint8 ?)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out16(OutputPtr, Value) \
> > ??{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out32(OutputPtr, Value) \
> > ??{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> >
> > #endif
>
>These macros are probably broken on powerpc.
>
> >
> > I think these are the defination of XIo_In32 and XIo_Out32. Also,
during
> > the compilation, there is no error to complain that "XIo_In32 or
XIo_Out32
> > undeclared".
> >
>
>I would suggest you remove that part of the header file completely, and
>replace it with:
>
>#define XIo_In32(p) in_le32(x)
>#define XIO_Out32(p,v) out_le32(p, v)
>
> Arnd <><
_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: MPC5200B SPI PSC3 Problem
From: John Rigby @ 2006-06-08 16:04 UTC (permalink / raw)
To: Trueskew; +Cc: linuxppc-embedded
In-Reply-To: <44875165.40800d0c.36a8.3e2e@mx.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12350 bytes --]
There seems to be a conflict between two sections of the 5200 User manual.
In section 7.3 where port_config is documented the PSC3 configuration
bits (20:23)
defined as:
0000 = All PSC3 pins are GPIOs
0001 = USB2 on PSC3, no GPIOs available, see Note 3
001X = Reserved
0100 = UART functionality without CD
0101 = UARTe functionality with CD
0110 = CODEC3 functionality
0111 = CODEC3 functionality (with MCLK)
100X = SPI
101X = Reserved
1100 = SPI with UART3
1101 = SPI with UART3e
111X = SPI with CODEC3
but in the psc chapter in table 15-85 it says to set port config to
0x00000600 but
the description says "Select the Pin-Muxing for PSC3 Codec mode"
It appears that table 15-85 is wrong.
I have attached some spi code that is embedded in a touchscreen
driver. It might be helpful.
On 6/7/06, Trueskew <trueskew@gmail.com> wrote:
>
>
> We have an AIC26 codec connected to our Lite5200B platform via J21. I've
> used MPC5200BUG to configure PSC3 as an SPI master, along with some samples
> I've found online (including here) and some I received from Freescale.
> Although the transfers seem to be working as expected (please see the output
> file at the end of this message), I get only 0xffff back. This occurs
> whether or not the device is attached to J21. A scope shows that PSC3_8
> (SPI_SS) and PSC3_9 (SPI_CLK) are low at all times, and I'm concerned I'm
> still doing something wrong with respect to enabling SPI over PSC3.
>
> I'm including my driver initialization code, my write code, and output
> showing the write behavior. If someone could comment on it, I would greatly
> appreciate it... or if someone flat out has code to do this, I'd be happy to
> take it from you. I've seen a few variations, but whether I use them
> directly or modify them as I need to, I can't seem to get past this. Of
> course, any other suggestions are welcome.
>
> Thanks.
> Sal
>
> ---------------------------------------------------------------------------
> Initialization Code
> ---------------------------------------------------------------------------
> #define GPIO_PSC3_PORT_CONFIG_MASK 0x00000f00
> #ifdef SPI_USE_MCLK
> #define GPIO_PSC3_PORT_CONFIG 0x00000700 /* PSC3 mode with mclk */
> #else /* SPI_USE_MCLK */
> #define GPIO_PSC3_PORT_CONFIG 0x00000600 /* PSC3 mode */
> #endif /* SPI_USE_MCLK */
>
> #define CDM_PSC3_MCLK_ENABLE 0x00000080
> #define CDM_PSC3_MCLK_CONFIG 0x8020 /* Divide Fvco ftom 528 to
> 16Mhz */
>
> #define PSC3_SICR_REG_VALUE 0x0280f000 /* 16-bit select Codec SPI
> master
> mode, msb first,
> UseEOF=1.
> GenClk=1, SIM,
> CPOL and
> CPHA are
> function
> input */
> ...
> /* Select the Pin-Muxing for PSC3 Codec mode */
> gpio = (struct mpc52xx_gpio *) ioremap(MPC52xx_GPIO,
> sizeof(struct mpc52xx_gpio));
> if(gpio)
> {
> port_config = gpio->port_config;
> port_config &= ~GPIO_PSC3_PORT_CONFIG_MASK;
> port_config |= GPIO_PSC3_PORT_CONFIG;
> gpio->port_config = port_config;
> iounmap(gpio);
> }
> else
> {
> return(-1);
> }
>
> #ifdef SPI_USE_MCLK
> /* PSC clock enable */
> g_pCDM->clk_enables |= CDM_PSC3_MCLK_ENABLE;
> g_pCDM->mclken_div_psc3 = CDM_PSC3_MCLK_CONFIG;
> #endif /* SPI_USE_MCLK */
>
> /* Disable rx and tx */
> g_pPSC->command = MPC52xx_PSC_RST_RX;
> g_pPSC->command = MPC52xx_PSC_RST_TX;
> g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> g_pPSC->command = MPC52xx_PSC_RX_DISABLE | MPC52xx_PSC_TX_DISABLE;
>
> g_pPSC->mode = 0;
> g_pPSC->sicr = PSC3_SICR_REG_VALUE;
>
> #ifdef SPI_USE_MCLK
> g_pPSC->ccr=0x0703; /* set SCK and DSCKL delay */
> #else /* SPI_USE_MCLK */
> g_pPSC->ccr=0x0003; /* set SCK and DSCKL delay must be > 2 */
> #endif /* SPI_USE_MCLK */
>
> g_pPSC->ctur=0x00; /* Set DTL delay 2us */
> g_pPSC->ctlr=0x84;
>
> g_pPSC->rfalarm=100; /* Alarm values taken from SPI example sample
> */
> g_pPSC->tfalarm=1;
>
> g_pPSC->rfcntl &= 0xf8; /* 0 byte granularity */
> g_pPSC->tfcntl = 1;
>
> /* Enable rx & tx */
> g_pPSC->command = MPC52xx_PSC_RST_RX;
> g_pPSC->command = MPC52xx_PSC_RST_TX;
> g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
>
> ---------------------------------------------------------------------------
> Write code
> ---------------------------------------------------------------------------
> static int mpc52xx_spi_transfer(u16 *p_usBuffer, u16 p_usCount)
> {
> u16 usIndex, usTemp;
>
>
> printk("------------------------------------------------------\n");
> printk("Entry: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> g_pPSC->command = MPC52xx_PSC_RST_RX;
> g_pPSC->command = MPC52xx_PSC_RST_TX;
> g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> printk("TX-RX Enable: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
>
> /* Clean out the read FIFO */
> usIndex = 0;
> while(g_pPSC->mpc52xx_psc_status & MPC52xx_PSC_SR_RXRDY)
> {
> usTemp = g_pPSC->mpc52xx_psc_buffer_16;
> printk("Flushing Rx FIFO: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> usIndex++;
> if(usIndex == 10) return(-1);
> }
>
> /* Send out the buffer */
> g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_DISABLE;
> for(usIndex=0; usIndex<p_usCount; usIndex++)
> {
> printk("Sending %04x: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
> p_usBuffer[usIndex],
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> g_pPSC->mpc52xx_psc_buffer_16 = p_usBuffer[usIndex];
> printk("Sent: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> }
> g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> usTemp = 0;
> while(g_pPSC->tfnum)
> {
> printk("TFNUM Wait: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> usTemp++;
> if(usTemp == 10) return(-1);
> };
> printk("TxRDY: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> for(usIndex=0; usIndex<p_usCount; usIndex++)
> {
> usTemp = 0;
> while(!(g_pPSC->mpc52xx_psc_status &
> MPC52xx_PSC_SR_RXRDY))
> {
> printk("RxRDY Wait: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> udelay(100000);
> usTemp++;
> if(usTemp == 10) return(-1);
> };
> printk("RxRDY: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> p_usBuffer[usIndex] = g_pPSC->mpc52xx_psc_buffer_16;
> printk(" Received %04x\n", p_usBuffer[usIndex]);
> }
>
> printk("EXIT: psc=%x status=%04x tfstat=%04x rfstat=%04x
> mode=%02x\n tfnum %3d rfnum %3d\n",
>
> (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> g_pPSC->tfnum, g_pPSC->rfnum);
> return(usIndex);
> }
>
>
> ---------------------------------------------------------------------------
> Output
> ---------------------------------------------------------------------------
> The lines below are a capture of register settings from my driver,
> along with output lines when trying to write 16 bit words to our
> device. This output is consistent whether the device is connected
> or not (via J21). Basic operation, delimited by "------...---":
>
> - Disable TX, Enable RX (despite the "TX-RX Enable" heading)
> - Send word 1
> - Send word 2
> - Enable TX, Enable RX
> - Wait for tfnum == 0
> - Receive data
>
> port_config=91051624 sicr=0280f000 clk_enables=00ffffff div_psc3=800f
> ------------------------------------------------------
> Entry: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> tfnum 0 rfnum 0
> TX-RX Enable: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> tfnum 0 rfnum 0
> Sending 0880: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 0
> Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 2 rfnum 0
> Sending bb00: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 2 rfnum 0
> Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 4 rfnum 0
> TFNUM Wait: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 2 rfnum 0
> TxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 4
> RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 4
> Received ffff
> RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 2
> Received ffff
> EXIT: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 0
> ------------------------------------------------------
> Entry: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 0
> TX-RX Enable: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> tfnum 0 rfnum 0
> Sending 8820: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 0
> Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 2 rfnum 0
> Sending 0000: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 2 rfnum 0
> Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 4 rfnum 0
> TFNUM Wait: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> tfnum 2 rfnum 0
> TxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 4
> RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 4
> Received ffff
> RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 2
> Received ffff
> EXIT: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> tfnum 0 rfnum 0
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: mpc5200_ts_spi.c --]
[-- Type: text/plain, Size: 6172 bytes --]
/*
* Media5200 touchscreen driver
*
* Copyright (c) 2006 Freescale
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
/*
File : mpc5200_ts_spi.c
Summary : touchscreen spi driver
*/
#include "mpc5200_ts_spi.h"
#include "asm/io.h"
/**************** Public functions ****************/
/*
Initialize and configure spi
- configure mux port on psc3
- configure spi mode
- configure spi baud rate
*/
int spi_init (void)
{
struct mpc52xx_gpio __iomem *gpio;
struct mpc52xx_intr __iomem *intr;
/* Map zones */
gpio = ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
intr = ioremap(MPC52xx_PA(MPC52xx_INTR_OFFSET), MPC52xx_INTR_SIZE);
if (!gpio || !intr) {
printk(KERN_ERR __FILE__ ": "
"Error while mapping GPIO/INTR during "
"spi_init\n");
goto unmap_regs;
}
SPI_Config_T spi_config; /* spi configuration */
PDEBUG3("spin_init: initializing SPI in spi_init()\n");
/* enable interrupt */
intr->per_mask &= INTR_PER_MASK_SPI_OFF;
/* initialize mux port PSC3 to SPI */
gpio->port_config |= GPIO_CONFIG_PORT_SPI_MASK;
/* initialze data structure */
SPI_Regs = (SPI_Regs_T *)(SPI_BASE_ADDRESS);
memset(&spi_config, 0, sizeof(SPI_Config_T));
/* set spi config attributes */
spi_config.SPI_Master = SPI_MASTER_DEFAULT;
spi_config.ClockPolarity = SPI_CPOL_DEFAULT;
spi_config.ClockPhase = SPI_CPHA_DEFAULT;
spi_config.WiredOR = SPI_WOR_DEFAULT;
spi_config.SSoutput = SPI_SSOE_DEFAULT;
spi_config.SPI_Enable = SPI_SPE_DEFAULT;
spi_config.BaudRate = SPI_BAUD_DEFAULT;
/* modify according to touchscreen driver spi config */
spi_config.ClockPolarity = 0;
spi_config.ClockPhase = 0 ;
spi_config.WiredOR = 0;
/*Set the SS pin to low by set SPIPORT register*/
SPI_Regs->SPIPORT = 0x00;
/* now initialize the spi hardware */
SPI_SetConfig(&spi_config);
/* Unmap reg zone */
unmap_regs:
if (gpio) iounmap(gpio);
if (intr) iounmap(intr);
return (TS_OK);
}
/* assume *buffer already alocated to be at least nbytes long */
int read_spi(u8 *buffer, u32 nbytes)
{
int i;
for (i = 0; i < nbytes; i++) {
buffer[i] = ReadRegister(SPI_Regs->SPIDR);
} /* for */
return (nbytes);
} /* read_spi */
int write_spi( u8 *buffer, u32 nbytes)
{
u32 len;
u8 reg_value;
// Move this to one devctl command
// SPI_Regs->SPIPORT = 0x00;
for ( len = 0; len < nbytes; len++ )
{
PDEBUG9("in write_spi: buffer = %x\n", *buffer);
WriteRegister(SPI_Regs->SPIDR,*buffer);
/* Wait several nanoseconds and then check the WCOL flag in status
* register. WeiWei systest replace it with the for-loop directly
*/
// WAIT(NANOSECS_PER_WRITE);
while(1)
{
reg_value = ReadRegister(SPI_Regs->SPISR);
if (reg_value & SPI_WCOL)
{
WriteRegister(SPI_Regs->SPIDR,*buffer);
continue;
}
if ( reg_value & SPI_SPIF )
break;
}
//SPI_Isr();
buffer++;
}
/* WeiWei add : hardware team suggestion, but it is optional */
// SPI_Regs->SPIPORT = 0x08;
return len;
}
/*************** Private functions ********************/
static int SPI_SetConfig(SPI_Config_T * Config_Ptr )
{
u8 control_reg = 0x00;
/* initialize direction register for SPI */
WriteRegister ( SPI_Regs->SPIDDR, 0x0e );
/* Set Baud Rate */
if(SPI_SetBaudrate( Config_Ptr -> BaudRate) == TS_ERROR )
{
PDEBUG3("SPI_SetConfig: Error in Set baudrate \n");
WriteRegister(SPI_Regs->SPICR1, control_reg | SPI_SPE);
return TS_ERROR;
}
/* aways master */
control_reg |= SPI_MASTER_MODE;
/* The SSOE for master mode */
control_reg &= ~SPI_SSOE;
if(Config_Ptr -> ClockPolarity)
control_reg |= SPI_CPOL;
else
control_reg &= ~SPI_CPOL;
if(Config_Ptr -> ClockPhase)
control_reg |= SPI_CPHA;
else
control_reg &= ~SPI_CPHA;
if(Config_Ptr -> WiredOR)
control_reg |= SPI_SPWOM;
else
control_reg &= ~SPI_SPWOM;
/* always enable SPI */
control_reg |= SPI_SPE;
/* Enable the interrupt and set the register : WeiWei systest */
WriteRegister(SPI_Regs->SPICR1, control_reg | SPI_SPIE );
PDEBUG3("SPI_SetCconfig : SPICR1 =%x \n",SPI_Regs->SPICR1);
return TS_OK ;
}
static int SPI_SetBaudrate(u32 BaudRate)
{
int i;
u16 clockdivisor;
/* Compute the Clock Divisor from module clock divided by BaudRate */
clockdivisor = SPI_MODULE_CLOCK/BaudRate;
/* Find the value of the Baud Rate Register from the array.
* If no accurate value can be found, select the closest one
*/
for (i = 0; i < SPI_DIVISOR_NUM-1; i++)
{
if(( clockdivisor >= Clock_Divisor[i].clockdivisor ) && \
( clockdivisor < Clock_Divisor[i+1].clockdivisor))
{
u16 middle;
middle = (Clock_Divisor[i].clockdivisor + \
Clock_Divisor[i+1].clockdivisor)/2;
if ( clockdivisor <= middle ) {
WriteRegister(SPI_Regs->SPIBR, \
Clock_Divisor[i].reg_value);
PDEBUG3("SPI_SetBaudrate: Baudrate %d\n", SPI_MODULE_CLOCK/Clock_Divisor[i].clockdivisor);
} else {
WriteRegister(SPI_Regs->SPIBR, \
Clock_Divisor[i+1].reg_value);
PDEBUG3("SPI_SetBaudrate: Baudrate %d\n", SPI_MODULE_CLOCK/Clock_Divisor[i+1].clockdivisor);
}
return TS_OK;
}
}
if ( clockdivisor == Clock_Divisor[i].clockdivisor )
{
WriteRegister(SPI_Regs->SPIBR, Clock_Divisor[i].reg_value);
PDEBUG3("SPI_SetBaudrate: Exact Baudrate %d\n", SPI_MODULE_CLOCK/clockdivisor);
return TS_OK;
}
else
return TS_ERROR;
}
^ permalink raw reply
* Re: MPC5200B SPI PSC3 Problem
From: John Rigby @ 2006-06-08 16:11 UTC (permalink / raw)
To: Trueskew; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0606080904v52e3cbe1kf9585bc1b0ba26a5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13105 bytes --]
Here's an include file that goes with file in the last email.
On 6/8/06, John Rigby <jcrigby@gmail.com> wrote:
> There seems to be a conflict between two sections of the 5200 User manual.
> In section 7.3 where port_config is documented the PSC3 configuration
> bits (20:23)
> defined as:
>
> 0000 = All PSC3 pins are GPIOs
> 0001 = USB2 on PSC3, no GPIOs available, see Note 3
> 001X = Reserved
> 0100 = UART functionality without CD
> 0101 = UARTe functionality with CD
> 0110 = CODEC3 functionality
> 0111 = CODEC3 functionality (with MCLK)
> 100X = SPI
> 101X = Reserved
> 1100 = SPI with UART3
> 1101 = SPI with UART3e
> 111X = SPI with CODEC3
>
> but in the psc chapter in table 15-85 it says to set port config to
> 0x00000600 but
> the description says "Select the Pin-Muxing for PSC3 Codec mode"
>
> It appears that table 15-85 is wrong.
>
> I have attached some spi code that is embedded in a touchscreen
> driver. It might be helpful.
>
>
>
>
>
> On 6/7/06, Trueskew <trueskew@gmail.com> wrote:
> >
> >
> > We have an AIC26 codec connected to our Lite5200B platform via J21. I've
> > used MPC5200BUG to configure PSC3 as an SPI master, along with some samples
> > I've found online (including here) and some I received from Freescale.
> > Although the transfers seem to be working as expected (please see the output
> > file at the end of this message), I get only 0xffff back. This occurs
> > whether or not the device is attached to J21. A scope shows that PSC3_8
> > (SPI_SS) and PSC3_9 (SPI_CLK) are low at all times, and I'm concerned I'm
> > still doing something wrong with respect to enabling SPI over PSC3.
> >
> > I'm including my driver initialization code, my write code, and output
> > showing the write behavior. If someone could comment on it, I would greatly
> > appreciate it... or if someone flat out has code to do this, I'd be happy to
> > take it from you. I've seen a few variations, but whether I use them
> > directly or modify them as I need to, I can't seem to get past this. Of
> > course, any other suggestions are welcome.
> >
> > Thanks.
> > Sal
> >
> > ---------------------------------------------------------------------------
> > Initialization Code
> > ---------------------------------------------------------------------------
> > #define GPIO_PSC3_PORT_CONFIG_MASK 0x00000f00
> > #ifdef SPI_USE_MCLK
> > #define GPIO_PSC3_PORT_CONFIG 0x00000700 /* PSC3 mode with mclk */
> > #else /* SPI_USE_MCLK */
> > #define GPIO_PSC3_PORT_CONFIG 0x00000600 /* PSC3 mode */
> > #endif /* SPI_USE_MCLK */
> >
> > #define CDM_PSC3_MCLK_ENABLE 0x00000080
> > #define CDM_PSC3_MCLK_CONFIG 0x8020 /* Divide Fvco ftom 528 to
> > 16Mhz */
> >
> > #define PSC3_SICR_REG_VALUE 0x0280f000 /* 16-bit select Codec SPI
> > master
> > mode, msb first,
> > UseEOF=1.
> > GenClk=1, SIM,
> > CPOL and
> > CPHA are
> > function
> > input */
> > ...
> > /* Select the Pin-Muxing for PSC3 Codec mode */
> > gpio = (struct mpc52xx_gpio *) ioremap(MPC52xx_GPIO,
> > sizeof(struct mpc52xx_gpio));
> > if(gpio)
> > {
> > port_config = gpio->port_config;
> > port_config &= ~GPIO_PSC3_PORT_CONFIG_MASK;
> > port_config |= GPIO_PSC3_PORT_CONFIG;
> > gpio->port_config = port_config;
> > iounmap(gpio);
> > }
> > else
> > {
> > return(-1);
> > }
> >
> > #ifdef SPI_USE_MCLK
> > /* PSC clock enable */
> > g_pCDM->clk_enables |= CDM_PSC3_MCLK_ENABLE;
> > g_pCDM->mclken_div_psc3 = CDM_PSC3_MCLK_CONFIG;
> > #endif /* SPI_USE_MCLK */
> >
> > /* Disable rx and tx */
> > g_pPSC->command = MPC52xx_PSC_RST_RX;
> > g_pPSC->command = MPC52xx_PSC_RST_TX;
> > g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> > g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> > g_pPSC->command = MPC52xx_PSC_RX_DISABLE | MPC52xx_PSC_TX_DISABLE;
> >
> > g_pPSC->mode = 0;
> > g_pPSC->sicr = PSC3_SICR_REG_VALUE;
> >
> > #ifdef SPI_USE_MCLK
> > g_pPSC->ccr=0x0703; /* set SCK and DSCKL delay */
> > #else /* SPI_USE_MCLK */
> > g_pPSC->ccr=0x0003; /* set SCK and DSCKL delay must be > 2 */
> > #endif /* SPI_USE_MCLK */
> >
> > g_pPSC->ctur=0x00; /* Set DTL delay 2us */
> > g_pPSC->ctlr=0x84;
> >
> > g_pPSC->rfalarm=100; /* Alarm values taken from SPI example sample
> > */
> > g_pPSC->tfalarm=1;
> >
> > g_pPSC->rfcntl &= 0xf8; /* 0 byte granularity */
> > g_pPSC->tfcntl = 1;
> >
> > /* Enable rx & tx */
> > g_pPSC->command = MPC52xx_PSC_RST_RX;
> > g_pPSC->command = MPC52xx_PSC_RST_TX;
> > g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> > g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> >
> > ---------------------------------------------------------------------------
> > Write code
> > ---------------------------------------------------------------------------
> > static int mpc52xx_spi_transfer(u16 *p_usBuffer, u16 p_usCount)
> > {
> > u16 usIndex, usTemp;
> >
> >
> > printk("------------------------------------------------------\n");
> > printk("Entry: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > g_pPSC->command = MPC52xx_PSC_RST_RX;
> > g_pPSC->command = MPC52xx_PSC_RST_TX;
> > g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> > g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> > printk("TX-RX Enable: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> >
> > /* Clean out the read FIFO */
> > usIndex = 0;
> > while(g_pPSC->mpc52xx_psc_status & MPC52xx_PSC_SR_RXRDY)
> > {
> > usTemp = g_pPSC->mpc52xx_psc_buffer_16;
> > printk("Flushing Rx FIFO: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > usIndex++;
> > if(usIndex == 10) return(-1);
> > }
> >
> > /* Send out the buffer */
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_DISABLE;
> > for(usIndex=0; usIndex<p_usCount; usIndex++)
> > {
> > printk("Sending %04x: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> > p_usBuffer[usIndex],
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > g_pPSC->mpc52xx_psc_buffer_16 = p_usBuffer[usIndex];
> > printk("Sent: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > }
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> > usTemp = 0;
> > while(g_pPSC->tfnum)
> > {
> > printk("TFNUM Wait: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > usTemp++;
> > if(usTemp == 10) return(-1);
> > };
> > printk("TxRDY: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > for(usIndex=0; usIndex<p_usCount; usIndex++)
> > {
> > usTemp = 0;
> > while(!(g_pPSC->mpc52xx_psc_status &
> > MPC52xx_PSC_SR_RXRDY))
> > {
> > printk("RxRDY Wait: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > usTemp++;
> > if(usTemp == 10) return(-1);
> > };
> > printk("RxRDY: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > p_usBuffer[usIndex] = g_pPSC->mpc52xx_psc_buffer_16;
> > printk(" Received %04x\n", p_usBuffer[usIndex]);
> > }
> >
> > printk("EXIT: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> > (int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC->mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > return(usIndex);
> > }
> >
> >
> > ---------------------------------------------------------------------------
> > Output
> > ---------------------------------------------------------------------------
> > The lines below are a capture of register settings from my driver,
> > along with output lines when trying to write 16 bit words to our
> > device. This output is consistent whether the device is connected
> > or not (via J21). Basic operation, delimited by "------...---":
> >
> > - Disable TX, Enable RX (despite the "TX-RX Enable" heading)
> > - Send word 1
> > - Send word 2
> > - Enable TX, Enable RX
> > - Wait for tfnum == 0
> > - Receive data
> >
> > port_config=91051624 sicr=0280f000 clk_enables=00ffffff div_psc3=800f
> > ------------------------------------------------------
> > Entry: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> > tfnum 0 rfnum 0
> > TX-RX Enable: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> > tfnum 0 rfnum 0
> > Sending 0880: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sending bb00: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 4 rfnum 0
> > TFNUM Wait: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > TxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > Received ffff
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 2
> > Received ffff
> > EXIT: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > ------------------------------------------------------
> > Entry: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > TX-RX Enable: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> > tfnum 0 rfnum 0
> > Sending 8820: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sending 0000: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 4 rfnum 0
> > TFNUM Wait: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > TxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > Received ffff
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 2
> > Received ffff
> > EXIT: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
>
[-- Attachment #2: mpc5200_ts_spi.h --]
[-- Type: text/plain, Size: 3296 bytes --]
/*
* Media5200 touchscreen driver
*
* Copyright (c) 2006 Freescale
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*/
/*
File : "mpc5200_ts_spi.h"
Summary: spi header file
*/
#ifndef __MPC5200_TS_SPI_H
#define __MPC5200_TS_SPI_H
/* headers */
#include "mpc5200_ts_common.h"
#include "mpc5200_ts_spi_dfn.h"
typedef struct SPI_Config_Type
{
u8 SPI_Master; /* 1 = SPI device is Master; */
/* 0 = SPI device is Slave */
u8 ClockPolarity; /* 1 = Active-low clocks selected;*/
/* 0 = Active-high clocks selected */
u8 ClockPhase; /* Clock Phase */
u8 WiredOR; /* 1 = Wired-OR mode */
u8 SPI_Enable; /* 1 = SPI system enable */
u8 SSoutput; /* 1 = SS as general-purpose output*/
u32 BaudRate; /* Baud Rate ,the unit is KHz */
} SPI_Config_T;
typedef struct ClockDivisor_Type
{
u8 reg_value; /* The corresponding register value */
u16 clockdivisor; /* Clock Divisor */
} ClockDivisor_T;
/* The following are default values of SPI configuration : code review */
#define SPI_MASTER_DEFAULT 1
#define SPI_CPOL_DEFAULT 1
#define SPI_CPHA_DEFAULT 1
#define SPI_WOR_DEFAULT 1
#define SPI_SPE_DEFAULT 1
#define SPI_SSOE_DEFAULT 1 /*WeiWei add it for SSOE bit */
//#define SPI_BAUD_DEFAULT 206250 // with 66MHZ clock, should yield 320 divisor .. this may solve errata sheet where SPIF set before data ready below 200KHZ 50000
#define SPI_BAUD_DEFAULT 128900 // with 132MHz bus, 1024
//#define SPI_BAUD_DEFAULT 50000
#define RCVBUF_SIZE_DEFAULT 512
#define RCVBUF_MIN_SIZE 4
#define RCVBUF_MAX_SIZE 4096
#define MSG_MAX_SIZE 2048
#define BUFSIZE 512
/* setting for module clock is now 132MHZ for Media5200 */
#define SPI_MODULE_CLOCK 132000000
#define SPI_DIVISOR_NUM 36
#define NANOSECS_PER_WRITE 1000000
#define NANOSECS_FOR_WCOL 1000000
#define LOOPS 10
/* Clock Divisor Selections Array. All clock divisor selections the spi driver
* can support are arranged between 640 to 2048 in ascending order. The supported
* baudrate range will rely on the SPI module clock( system clock).
* Given 66MHz system clock, the baudrate ranged between 33000Hz to 100000Hz.
*/
/* For memory leak : up the baud rate to 100KHz */
ClockDivisor_T Clock_Divisor[SPI_DIVISOR_NUM] =
{ { 0x45, 320},{ 0x46, 640 }, { 0x56, 768 }, { 0x66, 896 }, { 0x76, 1024 }, { 0x47, 1280 }, { 0x57, 1536 },{ 0x67, 1792}, { 0x77, 2048 } };
SPI_Regs_T *SPI_Regs; /* spi register struct */
/* public function prototyping */
int spi_init (void);
int write_spi(u8 *buffer, u32 nbytes);
int read_spi(u8 *buffer, u32 nbytes);
/* private functions prototyping */
static int SPI_SetConfig(SPI_Config_T * Config_Ptr );
static int SPI_SetBaudrate( u32 BaudRate);
#endif
^ permalink raw reply
* Re: does Gianfar Ethernet Controller Version 1.1 support MARVELL 88E1111?
From: Andy Fleming @ 2006-06-08 16:15 UTC (permalink / raw)
To: 郭 剑非; +Cc: Linuxppc-embedded
In-Reply-To: <BAY113-F12840A9A3ACBD5515A1350988B0@phx.gbl>
On Jun 8, 2006, at 02:43, =E9=83=AD =E5=89=91=E9=9D=9E wrote:
> Hi all,
> I'm debugging my board with MPC 8540 and marvell 88e1111 designed =20
> on it.
> I'm sure the hardware connection is correct, and the phy's ID could =20=
> be read
> through terminal port. But anyway, phy can not work. I wonder if it =20=
> is the
> driver's problem? Since the Gianfar Ethernet Controller Version 1.1
> surpport 88e1011s, but some 88e1111's registers are different from
> 88e1011s'. Actually I'm a new guy to Linux. Has anybody ever used =20
> 88e1111
> phy in Linux envirenmemt? Please
> give me some points. Thank you!
> I have read the Gianfar ethernet controller driver, but it's =20
> difficult for
> me to find out the sofware flow.
It would be better if you upgraded to the latest kernel. The PHY =20
subsystem in the driver has changed significantly since version 1.1 =20
of the driver. What leads you to believe that the PHY doesn't work? =20=
What errors do you see? I'm fairly certain the 88e1111 works with =20
the 88e1011 driver, but it's been a while.
^ permalink raw reply
* Re: [PATCH 3/3] RTAS MSI
From: Jake Moilanen @ 2006-06-08 16:13 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060607225843.GW8934@localdomain>
Here's a version addressing Nathan's concerns.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Index: 2.6/drivers/pci/Makefile
===================================================================
--- 2.6.orig/drivers/pci/Makefile 2006-06-08 10:30:14.000000000 -0500
+++ 2.6/drivers/pci/Makefile 2006-06-08 10:30:21.000000000 -0500
@@ -26,7 +26,14 @@
obj-$(CONFIG_PPC64) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
-obj-$(CONFIG_PCI_MSI) += msi.o
+
+msiobj-$(CONFIG_X86) += msi.o msi-apic.o msi-intel.o
+msiobj-$(CONFIG_IA64) += msi.o msi-apic.o msi-intel.o
+msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-altix.o
+msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-altix.o
+msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
+
+obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
#
# ACPI Related PCI FW Functions
Index: 2.6/drivers/pci/msi-rtas.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ 2.6/drivers/pci/msi-rtas.c 2006-06-08 10:51:13.000000000 -0500
@@ -0,0 +1,150 @@
+/*
+ * Jake Moilanen <moilanen@austin.ibm.com>
+ * Copyright (C) 2006 IBM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/pci.h>
+#include <linux/irq.h>
+#include <asm/rtas.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+
+int rtas_enable_msi(struct pci_dev* pdev)
+{
+ int seq_num = 1;
+ int i;
+ int rc;
+ int query_token = rtas_token("ibm,query-interrupt-source-number");
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ int dummy;
+ unsigned int virq;
+ unsigned int addr;
+ unsigned long buid = -1;
+ struct device_node * dn;
+
+ BUG_ON(!pdev);
+
+ dn = pci_device_to_OF_node(pdev);
+
+ if (!of_find_property(dn, "ibm,req#msi", &dummy))
+ return -ENOENT;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return -ENXIO;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ do {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 0, 0, seq_num);
+
+ seq_num = ret[1];
+ } while (rtas_busy_delay(rc));
+
+ if (rc)
+ {
+ printk(KERN_WARNING "error[%d]: getting the number of "
+ "MSI interrupts for %s\n", rc, dn->name);
+ return -EIO;
+ }
+
+ /* Return if there's no MSI interrupts */
+ if (!ret[0])
+ return -ENOENT;
+
+ dn->n_intrs = ret[0];
+
+ dn->intrs = kmalloc(dn->n_intrs * sizeof(*(dn->intrs)), GFP_KERNEL);
+ if (!dn->intrs) {
+ printk(KERN_WARNING "rtas_enable_msi: can't allocate space\n");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < dn->n_intrs; i++) {
+ do {
+ rc = rtas_call(query_token, 4, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff, i);
+ } while (rtas_busy_delay(rc));
+
+ if (!rc) {
+ virq = virt_irq_create_mapping(ret[0]);
+
+ dn->intrs[i].line = irq_offset_up(virq);
+ dn->intrs[i].sense = ret[1];
+ } else {
+ printk(KERN_WARNING "error[%d]: query-interrupt-source-number for %s\n",
+ rc, dn->name);
+ }
+ }
+
+ /* Just give the first vector out for now */
+ pdev->irq = dn->intrs[0].line;
+
+ return 0;
+}
+
+void rtas_disable_msi(struct pci_dev* pdev)
+{
+ int seq_num = 1;
+ struct device_node * dn;
+ int rc;
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ int dummy;
+ unsigned int addr;
+ unsigned long buid = -1;
+
+ BUG_ON(!pdev);
+
+ dn = pci_device_to_OF_node(pdev);
+
+ if (!of_find_property(dn, "ibm,req#msi", &dummy))
+ return;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ do {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 2, 0, seq_num);
+
+ seq_num = ret[1];
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_WARNING "error[%d]: setting the number of "
+ "MSI interrupts for %s\n", rc, dn->name);
+ return;
+ }
+
+ dn->n_intrs = 0;
+
+ kfree(dn->intrs);
+}
Index: 2.6/drivers/pci/Kconfig
===================================================================
--- 2.6.orig/drivers/pci/Kconfig 2006-06-08 10:30:14.000000000 -0500
+++ 2.6/drivers/pci/Kconfig 2006-06-08 10:30:21.000000000 -0500
@@ -4,7 +4,7 @@
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
+ depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || PPC_PSERIES
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
Index: 2.6/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6.orig/arch/powerpc/platforms/pseries/setup.c 2006-06-08 10:30:14.000000000 -0500
+++ 2.6/arch/powerpc/platforms/pseries/setup.c 2006-06-08 10:30:21.000000000 -0500
@@ -205,6 +205,10 @@
} else {
ppc_md.init_IRQ = xics_init_IRQ;
ppc_md.get_irq = xics_get_irq;
+#ifdef CONFIG_PCI_MSI
+ ppc_md.enable_msi = rtas_enable_msi;
+ ppc_md.disable_msi = rtas_disable_msi;
+#endif
}
#ifdef CONFIG_SMP
Index: 2.6/include/asm-powerpc/rtas.h
===================================================================
--- 2.6.orig/include/asm-powerpc/rtas.h 2006-06-08 10:30:21.000000000 -0500
+++ 2.6/include/asm-powerpc/rtas.h 2006-06-08 10:30:21.000000000 -0500
@@ -4,6 +4,7 @@
#include <linux/spinlock.h>
#include <asm/page.h>
+#include <linux/pci.h>
/*
* Definitions for talking to the RTAS on CHRP machines.
@@ -182,6 +183,9 @@
extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
+extern int rtas_enable_msi(struct pci_dev* pdev);
+extern void rtas_disable_msi(struct pci_dev * pdev);
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
^ permalink raw reply
* Re: A Couple of 2.6/Xilinx Questions
From: Grant Likely @ 2006-06-08 17:17 UTC (permalink / raw)
To: rakirtley@bellsouth.net; +Cc: linuxppc-embedded
In-Reply-To: <20060608144535.RSPS5063.ibm70aec.bellsouth.net@mail.bellsouth.net>
On 6/8/06, rakirtley@bellsouth.net <rakirtley@bellsouth.net> wrote:
> All,
> I've been attempting to get a 2.6 version running on the Xilinx ML403 and only really need the ethernet and compact flash devices at this point. I've tried versions from mvista, kernel.org, etc; all only have the serial8250 device enabled. Obviously adding devices is a lot of work and it appears that you all have already made great progress enabling ethernet.
> Are any of the advanced versions upon which you all work generally available? If so could you please provide a location? Apologies in advance for polluting your emailboxes and thanks in advance for any help/pointers that you can provide. I'll be more than happy to share any mods that I make (if any)
Mvista published patches for a TEMAC driver a month or two ago onto
this mailing list. Last I heard, mvista will be releasing 2.6 support
for the V2/V4 parts by the end of this month.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* VFS: Cannot open root device ...
From: Chris Dumoulin @ 2006-06-08 17:20 UTC (permalink / raw)
To: linuxppc-embedded
I'm trying to port a 2.6 kernel to a V2Pro-based board that I've got. I
get the following output when trying to boot:
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
I'm trying to use an initrd RAMDISK, and I've made sure that RAMDISK and
initrd support are both enabled in the kernel configuration. Any ideas
would be appreciated.
Cheers,
Chris Dumoulin
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: does Gianfar Ethernet Controller Version 1.1 support MARVELL 88E1111?
From: Guo Jaffe @ 2006-06-08 17:51 UTC (permalink / raw)
To: afleming; +Cc: Linuxppc-embedded
In-Reply-To: <912A1A11-36AB-4E68-BC29-7F584270C4F0@freescale.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 1805 bytes --]
Hi Andy,
Thank you for your information. So the driver is not the issue, but better
to upgraded.
I will check the board once more. The PHY doesn't work because the 8bit bus
between MAC and PHY is locked(TX_EN and RX_DV all disabled from the scope's
view) and also you can't see any signals exist at the Magnetic side(nor LED
signals). It seems that only MDC/MDIO and CLOCK reference pin works. The
PHY's ID must be read from MDC/MDIO interface and Clocks are right showed
on the scope.
Best Regards,
Jaffe
>From: Andy Fleming <afleming@freescale.com>
>To: 郁\x7f 剑非 <jianfei616@hotmail.com>
>CC: Linuxppc-embedded@ozlabs.org
>Subject: Re: does Gianfar Ethernet Controller Version 1.1 support MARVELL
88E1111?
>Date: Thu, 8 Jun 2006 11:15:32 -0500
>
>
>On Jun 8, 2006, at 02:43, 郁\x7f 剑非 wrote:
>
>>Hi all,
>>I'm debugging my board with MPC 8540 and marvell 88e1111 designed
>>on it.
>>I'm sure the hardware connection is correct, and the phy's ID could
>> be read
>>through terminal port. But anyway, phy can not work. I wonder if it
>> is the
>>driver's problem? Since the Gianfar Ethernet Controller Version 1.1
>>surpport 88e1011s, but some 88e1111's registers are different from
>>88e1011s'. Actually I'm a new guy to Linux. Has anybody ever used
>>88e1111
>>phy in Linux envirenmemt? Please
>>give me some points. Thank you!
>>I have read the Gianfar ethernet controller driver, but it's
>>difficult for
>>me to find out the sofware flow.
>
>
>It would be better if you upgraded to the latest kernel. The PHY
>subsystem in the driver has changed significantly since version 1.1
>of the driver. What leads you to believe that the PHY doesn't work?
> What errors do you see? I'm fairly certain the 88e1111 works
>with the 88e1011 driver, but it's been a while.
>
^ permalink raw reply
* Re: VFS: Cannot open root device ...
From: Steve Iribarne (GMail) @ 2006-06-08 18:39 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <44885C45.7020009@ics-ltd.com>
On 6/8/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I'm trying to port a 2.6 kernel to a V2Pro-based board that I've got. I
> get the following output when trying to boot:
>
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> VFS: Cannot open root device "<NULL>" or unknown-block(0,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0)
What boot loader are you using? In the boot loader where does it
think the root fs is located? My guess is /dev/ram0 or something like
that?
So I'd check your ramdisk to see that it has a /dev/ram0.
Make sure you have rights to it.
-stv
>
> I'm trying to use an initrd RAMDISK, and I've made sure that RAMDISK and
> initrd support are both enabled in the kernel configuration. Any ideas
> would be appreciated.
>
> Cheers,
> Chris Dumoulin
> --
> *--Christopher Dumoulin--*
> Software Team Leader
>
> <http://ics-ltd.com/>
> <http://ics-ltd.com/>
>
> Interactive Circuits and Systems Ltd.
> 5430 Canotek Road
> Ottawa, ON
> K1J 9G2
> (613)749-9241
> 1-800-267-9794 (USA only)
>
> ------------------------------------------------------------------------
> This e-mail is private and confidential and is for the addressee only.
> If misdirected, please notify us by telephone and confirm that it has
> been deleted from your system and any hard copies destroyed. You are
> strictly prohibited from using, printing, distributing or disseminating
> it or any information contained in it save to the intended recipient.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: does Gianfar Ethernet Controller Version 1.1 support MARVELL 88E1111?
From: Andy Fleming @ 2006-06-08 19:25 UTC (permalink / raw)
To: Guo Jaffe; +Cc: Linuxppc-embedded
In-Reply-To: <BAY113-F70D5359537D7DC16B4678988B0@phx.gbl>
On Jun 8, 2006, at 12:51, Guo Jaffe wrote:
> Hi Andy,
>
> Thank you for your information. So the driver is not the issue, but
> better to upgraded.
>
> I will check the board once more. The PHY doesn't work because the
> 8bit bus between MAC and PHY is locked(TX_EN and RX_DV all disabled
> from the scope's view) and also you can't see any signals exist at
> the Magnetic side(nor LED signals). It seems that only MDC/MDIO and
> CLOCK reference pin works. The PHY's ID must be read from MDC/MDIO
> interface and Clocks are right showed on the scope.
But what error are you getting? What are the symptoms of your
problem? The GMII interface (the 8-bit bus) is inconsequential to
PHY configuration and management. Only the MDC/MDIO bus is used.
Therefore the PHY id should be quite readable. What version of Linux
are you using? Please describe what the kernel prints out when you
boot, and when you try to bring up the interface (assuming you don't
do that at boot).
Andy
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jeff Garzik @ 2006-06-08 19:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <1149720298.23938.207.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
> Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
ACK, but patch does not apply to netdev-2.6.git#upstream.
Jeff
^ permalink raw reply
* RE: MPC5200B SPI PSC3 Problem
From: Trueskew @ 2006-06-08 19:50 UTC (permalink / raw)
To: 'John Rigby'; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0606080911x5607f1fakbeee6a9b6e2cd6f1@mail.gmail.com>
Thanks John. I actually decided not to sleep last night and figured all of
that out, including the documentation conflict, and now I'm working. I
wasn't even sure my post work, I didn't receive it, but maybe the sender is
left out. I should've slept and waited for your reply.
I'm still a little confused though. I re-checked code from Freescale and
references and patches listed or mentioned here, and they all use either
0x06 or 0x07 for the GPIO port config, depending on whether they want MCLK
or not. The included SPI transfer routines use the PSC3 FIFO mechanism to
send and receive data. The biggest light bulb shot for how I figured out
what was going on was because I decided to hang a scope off the codec lines
of the PSC3, and that's where I found the data I was sending out. The
MPC5200B vs. MPC5200 doc from Freescale doesn't mention this area as
changed, so how do so many 5200 SPI solutions go this route? I wondered if
they worked on reference platforms that were using the codec lines to drive
SPI, which looks like it's doable, but some solutions advertise themselves
as MPC5200 SPI drivers. Another possibility is that they weren't tested.
And yet another, the one I'm concerned with, is that I'm still
misunderstanding something... hence the paragraph.
But in any case, thanks again, I appreciate the help.
-----Original Message-----
From: John Rigby [mailto:jcrigby@gmail.com]
Sent: Thursday, June 08, 2006 9:11 AM
To: Trueskew
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC5200B SPI PSC3 Problem
Here's an include file that goes with file in the last email.
On 6/8/06, John Rigby <jcrigby@gmail.com> wrote:
> There seems to be a conflict between two sections of the 5200 User manual.
> In section 7.3 where port_config is documented the PSC3 configuration
> bits (20:23) defined as:
>
> 0000 = All PSC3 pins are GPIOs
> 0001 = USB2 on PSC3, no GPIOs available, see Note 3 001X = Reserved
> 0100 = UART functionality without CD
> 0101 = UARTe functionality with CD
> 0110 = CODEC3 functionality
> 0111 = CODEC3 functionality (with MCLK) 100X = SPI 101X = Reserved
> 1100 = SPI with UART3
> 1101 = SPI with UART3e
> 111X = SPI with CODEC3
>
> but in the psc chapter in table 15-85 it says to set port config to
> 0x00000600 but the description says "Select the Pin-Muxing for PSC3
> Codec mode"
>
> It appears that table 15-85 is wrong.
>
> I have attached some spi code that is embedded in a touchscreen
> driver. It might be helpful.
>
>
>
>
>
> On 6/7/06, Trueskew <trueskew@gmail.com> wrote:
> >
> >
> > We have an AIC26 codec connected to our Lite5200B platform via J21.
> > I've used MPC5200BUG to configure PSC3 as an SPI master, along with
> > some samples I've found online (including here) and some I received from
Freescale.
> > Although the transfers seem to be working as expected (please see
> > the output file at the end of this message), I get only 0xffff back.
> > This occurs whether or not the device is attached to J21. A scope
> > shows that PSC3_8
> > (SPI_SS) and PSC3_9 (SPI_CLK) are low at all times, and I'm
> > concerned I'm still doing something wrong with respect to enabling SPI
over PSC3.
> >
> > I'm including my driver initialization code, my write code, and
> > output showing the write behavior. If someone could comment on it,
> > I would greatly appreciate it... or if someone flat out has code to
> > do this, I'd be happy to take it from you. I've seen a few
> > variations, but whether I use them directly or modify them as I need
> > to, I can't seem to get past this. Of course, any other suggestions are
welcome.
> >
> > Thanks.
> > Sal
> >
> > --------------------------------------------------------------------
> > -------
> > Initialization Code
> > --------------------------------------------------------------------
> > ------- #define GPIO_PSC3_PORT_CONFIG_MASK 0x00000f00 #ifdef
> > SPI_USE_MCLK
> > #define GPIO_PSC3_PORT_CONFIG 0x00000700 /* PSC3 mode with mclk
*/
> > #else /* SPI_USE_MCLK */
> > #define GPIO_PSC3_PORT_CONFIG 0x00000600 /* PSC3 mode */
> > #endif /* SPI_USE_MCLK */
> >
> > #define CDM_PSC3_MCLK_ENABLE 0x00000080
> > #define CDM_PSC3_MCLK_CONFIG 0x8020 /* Divide Fvco ftom 528
to
> > 16Mhz */
> >
> > #define PSC3_SICR_REG_VALUE 0x0280f000 /* 16-bit select Codec
SPI
> > master mode, msb
> > first,
> > UseEOF=1.
> > GenClk=1, SIM,
> > CPOL and CPHA are
> > function input */
> > ...
> > /* Select the Pin-Muxing for PSC3 Codec mode */
> > gpio = (struct mpc52xx_gpio *) ioremap(MPC52xx_GPIO,
> > sizeof(struct mpc52xx_gpio));
> > if(gpio)
> > {
> > port_config = gpio->port_config;
> > port_config &= ~GPIO_PSC3_PORT_CONFIG_MASK;
> > port_config |= GPIO_PSC3_PORT_CONFIG;
> > gpio->port_config = port_config;
> > iounmap(gpio);
> > }
> > else
> > {
> > return(-1);
> > }
> >
> > #ifdef SPI_USE_MCLK
> > /* PSC clock enable */
> > g_pCDM->clk_enables |= CDM_PSC3_MCLK_ENABLE;
> > g_pCDM->mclken_div_psc3 = CDM_PSC3_MCLK_CONFIG; #endif /*
> > SPI_USE_MCLK */
> >
> > /* Disable rx and tx */
> > g_pPSC->command = MPC52xx_PSC_RST_RX;
> > g_pPSC->command = MPC52xx_PSC_RST_TX;
> > g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> > g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> > g_pPSC->command = MPC52xx_PSC_RX_DISABLE |
> > MPC52xx_PSC_TX_DISABLE;
> >
> > g_pPSC->mode = 0;
> > g_pPSC->sicr = PSC3_SICR_REG_VALUE;
> >
> > #ifdef SPI_USE_MCLK
> > g_pPSC->ccr=0x0703; /* set SCK and DSCKL delay */
> > #else /* SPI_USE_MCLK */
> > g_pPSC->ccr=0x0003; /* set SCK and DSCKL delay must be > 2 */
> > #endif /* SPI_USE_MCLK */
> >
> > g_pPSC->ctur=0x00; /* Set DTL delay 2us */
> > g_pPSC->ctlr=0x84;
> >
> > g_pPSC->rfalarm=100; /* Alarm values taken from SPI example
sample
> > */
> > g_pPSC->tfalarm=1;
> >
> > g_pPSC->rfcntl &= 0xf8; /* 0 byte granularity */
> > g_pPSC->tfcntl = 1;
> >
> > /* Enable rx & tx */
> > g_pPSC->command = MPC52xx_PSC_RST_RX;
> > g_pPSC->command = MPC52xx_PSC_RST_TX;
> > g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> > g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> >
> > --------------------------------------------------------------------
> > -------
> > Write code
> > --------------------------------------------------------------------
> > ------- static int mpc52xx_spi_transfer(u16 *p_usBuffer, u16
> > p_usCount) {
> > u16 usIndex, usTemp;
> >
> >
> > printk("------------------------------------------------------\n");
> > printk("Entry: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > g_pPSC->command = MPC52xx_PSC_RST_RX;
> > g_pPSC->command = MPC52xx_PSC_RST_TX;
> > g_pPSC->command = MPC52xx_PSC_SEL_MODE_REG_1;
> > g_pPSC->command = MPC52xx_PSC_RST_ERR_STAT;
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> > printk("TX-RX Enable: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> >
> > /* Clean out the read FIFO */
> > usIndex = 0;
> > while(g_pPSC->mpc52xx_psc_status & MPC52xx_PSC_SR_RXRDY)
> > {
> > usTemp = g_pPSC->mpc52xx_psc_buffer_16;
> > printk("Flushing Rx FIFO: psc=%x status=%04x tfstat=%04x
rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > usIndex++;
> > if(usIndex == 10) return(-1);
> > }
> >
> > /* Send out the buffer */
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_DISABLE;
> > for(usIndex=0; usIndex<p_usCount; usIndex++)
> > {
> > printk("Sending %04x: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> > p_usBuffer[usIndex],
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > g_pPSC->mpc52xx_psc_buffer_16 = p_usBuffer[usIndex];
> > printk("Sent: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > }
> > g_pPSC->command = MPC52xx_PSC_RX_ENABLE | MPC52xx_PSC_TX_ENABLE;
> > usTemp = 0;
> > while(g_pPSC->tfnum)
> > {
> > printk("TFNUM Wait: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > usTemp++;
> > if(usTemp == 10) return(-1);
> > };
> > printk("TxRDY: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > for(usIndex=0; usIndex<p_usCount; usIndex++)
> > {
> > usTemp = 0;
> > while(!(g_pPSC->mpc52xx_psc_status &
> > MPC52xx_PSC_SR_RXRDY))
> > {
> > printk("RxRDY Wait: psc=%x status=%04x tfstat=%04x
rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > udelay(100000);
> > usTemp++;
> > if(usTemp == 10) return(-1);
> > };
> > printk("RxRDY: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > p_usBuffer[usIndex] = g_pPSC->mpc52xx_psc_buffer_16;
> > printk(" Received %04x\n", p_usBuffer[usIndex]);
> > }
> >
> > printk("EXIT: psc=%x status=%04x tfstat=%04x rfstat=%04x
> > mode=%02x\n tfnum %3d rfnum %3d\n",
> >
> >
(int)g_pPSC,g_pPSC->mpc52xx_psc_status,g_pPSC->tfstat,g_pPSC->tfstat,g_pPSC-
>mode,
> > g_pPSC->tfnum, g_pPSC->rfnum);
> > return(usIndex);
> > }
> >
> >
> > --------------------------------------------------------------------
> > -------
> > Output
> > --------------------------------------------------------------------
> > ------- The lines below are a capture of register settings from my
> > driver, along with output lines when trying to write 16 bit words to
> > our device. This output is consistent whether the device is
> > connected or not (via J21). Basic operation, delimited by
> > "------...---":
> >
> > - Disable TX, Enable RX (despite the "TX-RX Enable" heading)
> > - Send word 1
> > - Send word 2
> > - Enable TX, Enable RX
> > - Wait for tfnum == 0
> > - Receive data
> >
> > port_config=91051624 sicr=0280f000 clk_enables=00ffffff
> > div_psc3=800f
> > ------------------------------------------------------
> > Entry: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> > tfnum 0 rfnum 0
> > TX-RX Enable: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> > tfnum 0 rfnum 0
> > Sending 0880: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sending bb00: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 4 rfnum 0
> > TFNUM Wait: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > TxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > Received ffff
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 2
> > Received ffff
> > EXIT: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > ------------------------------------------------------
> > Entry: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > TX-RX Enable: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=33
> > tfnum 0 rfnum 0
> > Sending 8820: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sending 0000: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > Sent: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 4 rfnum 0
> > TFNUM Wait: psc=f0002400 status=0000 tfstat=0002 rfstat=0002 mode=07
> > tfnum 2 rfnum 0
> > TxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 4
> > Received ffff
> > RxRDY: psc=f0002400 status=0500 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 2
> > Received ffff
> > EXIT: psc=f0002400 status=0400 tfstat=0003 rfstat=0003 mode=07
> > tfnum 0 rfnum 0
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
>
^ permalink raw reply
* Re: [PATCH 9/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 20:13 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev@ozlabs.org, netdev
In-Reply-To: <44887BD3.7000009@garzik.org>
On Thu, 2006-06-08 at 14:34, Jeff Garzik wrote:
> Jon Loeliger wrote:
> > Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
> > Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> ACK, but patch does not apply to netdev-2.6.git#upstream.
>
> Jeff
Thanks, Jeff.
Are you willing to take the netdev parts as-is, then?
Or would you like me to reformat the netdev parts to
apply against the netdev-2.6.git#upstream branch?
The patch is currently for the Paul Mackerras powerpc.git
tree as it stands now. Should we apply it through that
path now as you have ACK'ed it?
Thanks,
jdl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox