Volunteers to test i2c-algo-8xx on v2.6?
In message 20050809052142.2C53242C5E at denx.de you wrote: I'm working with Wolfgang's ELDK-3.1.1, diff against Wolfgang's ELDK-3.1.1 patch is attached. Ummm... A quick scan showed only reformatting and style changes. I think someone who really understands the controller should perform a review of the code. There are most likely problems hidden - like the timeout of 1 second which is much too short; we measured nearly 4 seconds (under heavy load) between starting a transfer and getting the interrupt. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Work 8 hours, sleep 8 hours; but not the same 8 hours.
about building RTAI 24.1.12 at Linux 2.4.25
In message 1123568715.4219.7.camel at banana you wrote: I got some error while make RTAI, anybody know how to fix it please tell me,thanks. Use current code and current documentation. See ftp://ftp.denx.de/pub/RTAI/README [root at banana rtai-24.1.12]# make Don't use rtai-24.1.12 any more, it's too old. We support RTAI version 3.0r5 (kilauea) and 24.1.13 (stromboli); see the README. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de If all the Chinese simultaneously jumped into the Pacific off a 10 foot platform erected 10 feet off their coast, it would cause a tidal wave that would destroy everything in this country west of Nebraska.
Some version different
Dear Denk: I want to ask some questions about the different version: 1. The linuxppc_2_4_devel and the linux-2.4.25.tar.bz2 in ELDK 3.1.1 package 2. The ppcboot 0.9.2 compiled with mvstia devrock andthe U-Boot 1.1.2 compiled with ELDK Does the kernel freeze at transferring control to linux could be these different versions? Another question: 1 why I configed the kernel with CONFIG_HD860 in make menuconfig but the code in CONFIG_HD860 isn't compiled at all ! What's the perhaps reasons? I checked the Makefile and the .config, there is all with CONFIG_HD860 = y , But I add any string to CONFIG_HD860 code, there is nothing error when compiled ! 2 How to get board info struct bd_info in init/main.c ? I want to use printf of bd_t-bi_mon_fnc-printf() to print some string on console. Does it possible? But the code is only in head_8xx.S, How to get the bd* data in main.c ? Some board use get_board_info(). But how can I use it? thanks!
Some version different
In message A9DE2BAF233E444FA9C5E77A5825A01E86505B at ydmail.sbell.com.cn you wrote: I want to ask some questions about the different version: 1. The linuxppc_2_4_devel and the linux-2.4.25.tar.bz2 in ELDK 3.1.1 package THe traball is a snapshot from the linuxppc_2_4_devel CVS tree (for ELDK 3.1.1 the date of the snapshot is 2005-03-06 or CVS tag LABEL_2005_03_06_0100). 2. The ppcboot 0.9.2 compiled with mvstia devrock andthe U-Boot 1.1.2 compiled with ELDK PPCBoot 0.9.2 and U-Boot 1.1.2 are about 4 years apart. This is like comparing Linux kernel versions 2.0 with 2.6 Does the kernel freeze at transferring control to linux could be these different versions? Both versions were perfectly capable of booting a working Linux kernel. I don't know the MV toolchain, but I guess it's working fine, too. So my guess is that it's your port of the Linux kernel which is broken. 1 why I configed the kernel with CONFIG_HD860 in make menuconfig but the code in CONFIG_HD860 isn't compiled at all ! What's the perhaps reasons? I checked the Your port of the Linux kernel is broken. Probably you made errors when changing the configure scripts and/or Makefiles. 2 How to get board info struct bd_info in init/main.c ? I want to use printf of bd_t-bi_mon_fnc-printf() to You cannot do that. It does not work. print some string on console. Does it possible? But the code is only in head_8xx.S, How to get the bd* data in The _res pointer can be used for that; see the existing driver sources. main.c ? Some board use get_board_info(). But how can I use it? This depends on how your hardware and your port of Linux support such a feature. I cannot answer such a question. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The POP3 server service depends on the SMTP server service, which failed to start because of the following error: The operation comple- ted successfully. -- Windows NT Server v3.51
??: Some version different
Dear Denk: First I many thanks for your quick reply for my every silly question. The freeze transferring control to linux question is sloved. It is the r3 register data wrong transfer from ppcboot to kernel. I don't know why. very strange. !!! The CONFIG_HD860 cannot be compiled in kernel. I don't know either. There is no error or warring during config and make. I add the init code of bdinfo struct in arch/ppc/kernel/m8xx_setup.c platform_init() function. I filled the stuct __as list by bdi command. Then the console can work now. But there is another question: It always print the ttyS0 at 0x0280 is on SMC1 using BRGSerial driver version 5.05c (2001-07-08) with no serial options enabled or Serial driver version 5.05c (2001-07-08) with no serial options enabled Then Oops: kernel access of bad area, sig: 11 and stopped. How is the with no serial options enabled ? is it need any config with make menuconfig ? -- ???: wd at denx.de [mailto:wd at denx.de] : 2005?8?10? 13:25 ???: FCG WANG Baohua ??: linuxppc-embedded at ozlabs.org ??: Re: Some version different In message A9DE2BAF233E444FA9C5E77A5825A01E86505B at ydmail.sbell.com.cn you wrote: I want to ask some questions about the different version: 1. The linuxppc_2_4_devel and the linux-2.4.25.tar.bz2 in ELDK 3.1.1 package THe traball is a snapshot from the linuxppc_2_4_devel CVS tree (for ELDK 3.1.1 the date of the snapshot is 2005-03-06 or CVS tag LABEL_2005_03_06_0100). 2. The ppcboot 0.9.2 compiled with mvstia devrock andthe U-Boot 1.1.2 compiled with ELDK PPCBoot 0.9.2 and U-Boot 1.1.2 are about 4 years apart. This is like comparing Linux kernel versions 2.0 with 2.6 Does the kernel freeze at transferring control to linux could be these different versions? Both versions were perfectly capable of booting a working Linux kernel. I don't know the MV toolchain, but I guess it's working fine, too. So my guess is that it's your port of the Linux kernel which is broken. 1 why I configed the kernel with CONFIG_HD860 in make menuconfig but the code in CONFIG_HD860 isn't compiled at all ! What's the perhaps reasons? I checked the Your port of the Linux kernel is broken. Probably you made errors when changing the configure scripts and/or Makefiles. 2 How to get board info struct bd_info in init/main.c ? I want to use printf of bd_t-bi_mon_fnc-printf() to You cannot do that. It does not work. print some string on console. Does it possible? But the code is only in head_8xx.S, How to get the bd* data in The _res pointer can be used for that; see the existing driver sources. main.c ? Some board use get_board_info(). But how can I use it? This depends on how your hardware and your port of Linux support such a feature. I cannot answer such a question. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de The POP3 server service depends on the SMTP server service, which failed to start because of the following error: The operation comple- ted successfully. -- Windows NT Server v3.51
fs_enet on MPC885ADS
Hi, Peter Schaefer-Hutter, Peter wrote: Hi there, Are there any boot options needed to enable the fs_enet driver on the MPC885ADS? I replaced CONFIG_DUET with CONFIG_MPC885ADS in drivers/net/fs_enet/mac-fec.c, but only got fs_enet.c:v0.1 (May 6, 2005) NET: Registered protocol family 2 IP route cache hash table entries: 128 (order: -3, 512 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP reno registered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 IP-Config: Device `eth0' not found. Since this driver is platform-device based, you need to configure the PD structures. I'll try to submit a patch which will cover this... Reason i'm asking is that the current cpm_uart driver doesn't work with the SCC3 ethernet driver included in the MPC885 board support (as soon as ethernet is initialized, console output stops). This is very interesting since AFAIR SCC3 eth will not work with SMC2 on my board, but maybe something is changed. Anyway, oue fs_enet is pretty close to upstream so it would be nice if you will use (and test :)) it. Best regards, Peter ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Sincerely, Vitaly
??: Some version different
In message A9DE2BAF233E444FA9C5E77A5825A01E86505D at ydmail.sbell.com.cn you wrote: It is the r3 register data wrong transfer from ppcboot to kernel. I don't know why. very strange. !!! I'm sure that PPCBoot passes a valid pointer. If you don;t see the expected data, then you should probably go back to square one and read the FAQ: http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel The CONFIG_HD860 cannot be compiled in kernel. I don't know either. There is no error or warring during config and make. There is a bug (at least one) n your modifications to the Linux kernel. Then Oops: kernel access of bad area, sig: 11 and stopped. How is the with no serial options enabled ? is it need any config with make menuconfig ? I don't know your hardware. I don't know why you are using obsolete versions of the software (like PPCBoot) for any current work. I don't know which modifications you made to U-Boot to make it work on your hardware, or if these modifications are working at all. I don't know which modifications you made to Linux. I cannot help you. Hire an expert. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de There is nothing in this world constant but inconstancy. - Swift
sdram control register
Hi all, Does anyone know how to enable the bit mode_en in SDRAM Control Register (MBAR + 0x0104) ... I have been struggling for that .. Just briefly about this register.. writing is not allowed to this register when mode_en bit = '0', to unlock it we should write mode_en = '1', trying to do this directly makes the core restart , i think this should be enabled VIA some command or s0mething.. any help please ... Thanks for the reply in Advance .. nSr
fs_enet on MPC885ADS
From: Vitaly Bordug [mailto:vbordug at ru.mvista.com] Sent: Wednesday, August 10, 2005 9:26 AM Schaefer-Hutter, Peter wrote: Reason i'm asking is that the current cpm_uart driver doesn't work with the SCC3 ethernet driver included in the MPC885 board support (as soon as ethernet is initialized, console output stops). This is very interesting since AFAIR SCC3 eth will not work with SMC2 on my board, but maybe something is changed. Well, SMC2 ist disabled in the config, the DIP switches are set for 10BaseT... But i must confess that i've not looked very deep into that. Anyway, oue fs_enet is pretty close to upstream so it would be nice if you will use (and test :)) it. Sure! I'm your guinea pig :) Best regards, Peter
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
Hi all,
I had some problems on my MPC855M based board when I tried to access the
i2c bus.
The cause were some disturbances on the i2c bus. If a slave device or
another master device hold the SDA or SCL line low, the CPM will get into a
state, where no more transmissions are made. The only way I found, to get
the CPM back to work, was a complete re-initialisation. - force_reinit()
In this case the busy-wait for transmissions with count 16 will lock the
complete system (CPU load 99.9%)
I added the define I2C_BUSY_WAIT to switch between faster access or safer
system.
I found out that the i2c-algo-8xx.c has a bug in cpm_iic_read() and
cpm_iic_write(): the timeout detection will not work in the case of count
16.
I also added the define I2C_INTERRUPTIBLE_SLEEP: the old driver reported
IO-error (-EIO) if a timeout occured (which was not working, see above) or
if a signal was pending. This caused some problems if the process receives
user-signals. The driver will report IO-error, which is not correct. With
the busy-wait this effect might not be seen, because there will be no
process scheduling - no signals might be send.
My modified file is appended. The defines for I2C_BUSY_WAIT and
I2C_INTERRUPTIBLE_SLEEP are active, which let the driver act like the old
one.
Maybe this is helpful for others too and some of the modifications find
it?s way into the official kernel tree.
Cajus Hahn
/*
* i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM
* Copyright (c) 1999 Dan Malek (dmalek at jlc.net).
*
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; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* moved into proper i2c interface; separated out platform specific
* parts into i2c-rpx.c
* Brad Parker (brad at heeltoe.com)
*
* added define for BUSY_WAIT and INTERRUPTIBLE_SLEEP, added
I2C_ALGO_8XX_DATE + ..VERSION
* fixed bug in cpm_iic_read and cpm_iic_write (timeout never detected if
count 16)
* added force_reinit(): in certain cases (disturbances on the I2C bus) a
timeout will
* occur. After this a complete re-initialisation will be necessary,
otherwise all
* following transmissions will have a timeout.
* Cajus Hahn, 09.08.2005
*/
// XXX todo
// timeout sleep?
/* $Id: i2c-algo-8xx.c,v 1.1.1.1 2004/12/10 08:44:35 cajus Exp $ */
#include linux/kernel.h
#include linux/module.h
#include linux/delay.h
#include linux/slab.h
#include linux/version.h
#include linux/init.h
#include asm/uaccess.h
#include linux/ioport.h
#include linux/errno.h
#include linux/sched.h
#include asm/mpc8xx.h
#include asm/commproc.h
#include linux/i2c.h
#include linux/i2c-algo-8xx.h
#define I2C_ALGO_8XX_DATE 20050809
#define I2C_ALGO_8XX_VERSION 2.6.2
#define CPM_MAX_READ513
/* #define I2C_CHIP_ERRATA */ /* Try uncomment this if you have an older
CPU(earlier than rev D4) */
#define I2C_BUSY_WAIT /* Uncomment this if you want to do a busy wait in
cpm_iic_read and cpm_iic_write */
#define I2C_INTERRUPTIBLE_SLEEP /* Uncomment this if you want the waiting
in cpm_iic_read and
cpm_iic_write beeing interruptable
by signals */
static wait_queue_head_t iic_wait;
static ushort r_tbase, r_rbase;
int cpm_scan = 0;
int cpm_debug = 0;
static void
cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
{
volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
if (cpm_debug 1)
printk(KERN_DEBUG cpm_iic_interrupt(dev_id=%p)\n, dev_id);
#ifdef I2C_CHIP_ERRATA
/* Chip errata, clear enable.
* This seems to not be needed on rev D4 or newer CPUs.
* Someone with an older CPU needs to verify this.
*/
i2c-i2c_i2mod = ~1;
#endif
/* Clear interrupt.
*/
i2c-i2c_i2cer = 0xff;
/* Get 'me going again.
*/
#ifdef I2C_INTERRUPTIBLE_SLEEP
wake_up_interruptible(iic_wait);
#else
wake_up(iic_wait);
#endif
}
static void
cpm_iic_init(struct i2c_algo_8xx_data *cpm_adap)
{
volatile iic_t *iip = cpm_adap-iip;
volatile i2c8xx_t *i2c = cpm_adap-i2c;
unsigned char brg;
bd_t *bd = (bd_t *)__res;
if (cpm_debug) printk(KERN_DEBUG cpm_iic_init() - iip=%p\n,iip);
/* Initialize the parameter ram.
* We need to make sure many things are initialized to zero,
* especially in the case of a microcode patch.
*/
iip-iic_rstate = 0;
iip-iic_rdp = 0;
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
Hello, cajus.hahn
In message 2005-08-10 15:27:57 cajus.hahn at de.abb.com you wrote:
Hi all,
I had some problems on my MPC855M based board when I tried to access the
i2c bus.
Try update i2c-algo-8xx.c
= = = = = = = = = = = = = = = = = = = =
Debora Liu
deboralh at fel.com.cn
2005-08-10
begin 600 i2c_algo_8xx-port_to_2_6.patch
M.'AX.B!P;W)T(DR8RUA;=O7SAX!T;R`R+C8-@T*0F%S960@;VX at 5]M
M(%)I;FDGR!A;F0 at 2F]A:VEM(%1J97)N;'5N9=S('=OFL-@T*4VEG;F5D
M+6]F9BUB3H at 07)IW1E=2!397)G:[EMAIL PROTECTED]:VD at 1FEL:\@/%R:7-`
M8V%T:5DF%L;%BRYOF^#0H-DEN95X.B`R+C8M.'AX+V1R:79EG,O
M:3)C+V%L9V]S+VDR8RUA;=O+3AXYC#0H]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]#0HM+2T at +V1E=B]N=6QL3$Y-S`M,#$M,#$@,#`Z,#`Z,#`N,#`P,#`P
M,#`P(LP,#`P#0HK*RL@,BXV+3AX]DFEV97)S+VDR8R]A;=OR]I,F,M
M86QG;RTX'@N8PDR,#`U+3`X+3`X(#`Y.C4U.C,P+C`P,#`P,#`P,`M,#,P
M,[EMAIL PROTECTED],`K,2PV,3@0$`-[EMAIL PROTECTED](DR8RUA;=O+3AXYC
M(DR!DFEV97(@86QG;W)I=AMR!F;W(@35!#.%A8($-030T**R`J($-O
M'ER:6=H=`H8RD@,3DY.2!$86X at [EMAIL PROTECTED]1M86QE:T!J;,N;F5T*2X-
M[EMAIL PROTECTED]@T**R`@(!4:ES('!R;V=R86T@:7, at 9G)E92!S;V9T=V%R93L@6]U
M(-A;B!R961IW1R:6)U=4@:70 at 86YD+V]R(UO9EF0T**R`@(!I=!U
M;F1EB!T:[EMAIL PROTECTED]5R;7,@;[EMAIL
PROTECTED]AE($=.52!'96YEF%L(%!U8FQI8R!,:6-E
M;G-E(%S('!U8FQIVAE9!B0T**R`@(!T:4 at 1G)E92!3;V9T=V%R92!
M;W5N9%T:6]N.R!E:71H97(@=F5RVEO;B`R(]F('1H92!,:6-E;G-E+!O
M@T**R`@(`H870@6]UB!O'1I;VXI(%N2!L871EB!V97)S:6]N+ at T*
M*PT**R`@(!4:ES('!R;V=R86T@:7, at 9ES=')I8G5T960@:[EMAIL PROTECTED]AE(AO
M[EMAIL PROTECTED]AA=!I=!W:6QL()E('5S969U;P-BL@([EMAIL
PROTECTED](%=)5$A/550@
M04Y9(%=!4E)!3E19.R!W:71H;W5T([EMAIL PROTECTED]AE(EM[EMAIL PROTECTED]F%N
M='D@;V8-BL@([EMAIL PROTECTED],2519(]R($9)5$Y%4U, at 1D]2($$@
M4$%25$E#54Q!4B!055)[EMAIL PROTECTED]('1H90T**R`@(!'3E4 at 1V5N97)A
M;!0=6)L:6, at 3EC96YS92!F;W(@;6]R92!D971A:6QS+ at T**PT**R`@(!9
M;W4@VAO=6QD(AA=F4@F5C96EV960 at 82!C;W!Y(]F('1H92!'3E4 at 1V5N
M97)A;!0=6)L:6, at 3EC96YS90T**R`@(!A;]N9R!W:71H('1H:7,@')O
M9W)A;3L@:68@;F]T+!WFET92!T;R!T:4 at 1G)E92!3;V9T=V%R90T**R`@
M(!;W5N9%T:6]N+!);F,N+`V-S4 at 36%SR!!=F4L($-A;6)R:61G92P@
M34$@,#(Q,SDL(%5302X-[EMAIL PROTECTED]@T**R`J(UO=F5D(EN=\@')O5R(DR
M8R!I;G1EF9A8V4[('-E%R871E9!O=70@QA=9OFT@W!E8VEF:6,-
M[EMAIL PROTECTED])TR!I;G1O(DR8RUR'@N8PT**R`J($)R860 at 4%R:V5R(AB
MF%D0AE96QT;V4N8V]M*0T**R`J+PT**PT**R\O(%A86!T;V1O#0HK+R\@
M=EM96]U=!S;5E#\-BL-BLO*B`D260Z(DR8RUA;=O+3AXYC+'8@
M,2XW(#(P,#(O,[EMAIL PROTECTED],#,@,C([EMAIL
PROTECTED],3@@86,Y-#$P($5X`D(HO#0HK#0HK
M(VEN8VQU94@/QI;G5X+VMEFYE;YH/@T**R-I;F-L=61E(#QL:6YU]M
M;V1U;4N:#X-BLC:6YC;'5D92`\;EN=7 at O95L87DN:#X-BLC:6YC;'5D
M92`\;EN=7 at OVQA8BYH/@T**R-I;F-L=61E(#QL:6YU]V97)S:[EMAIL PROTECTED]
M#0HK(VEN8VQU94@/QI;G5X+VEN:70N:#X-BLC:6YC;'5D92`\87-M+W5A
M8V-EW,N:#X-BLC:6YC;'5D92`\;EN=7 at O:6]P;W)[EMAIL PROTECTED](VEN8VQU
M94@/QI;G5X+V5R[EMAIL PROTECTED](VEN8VQU94@/QI;G5X+W-C:[EMAIL PROTECTED]
M#0HK#0HK(VEN8VQU94@/%S;2]M,X'@N:#X-BLC:6YC;'5D92`\87-M
M+V-O;6UP[EMAIL PROTECTED](VEN8VQU94@/QI;G5X+VDR8RYH/@T**R-I
M;F-L=61E(#QL:6YU]I,F,M86QG;RTX'@N:#X-BL-BLC95F:6YE($-0
M35]-05A?4D5!1`DU,3,-BLO*B!4[EMAIL PROTECTED];VUM96YT('1H:7,@:68@6]U
M(AA=F4 at 86X@;VQD97(@0U!5*5AFQI97(@=AA;B!R978 at 1#0I(HO#0HK
M+RH@(V1E9FEN92!),D-?0TA)4%]%4E)[EMAIL PROTECTED]BL-BMS=%T:6, at 8VAA
MB`J;6]D=6QE7VYA;64@/2`B:3)C7V%L9V]?.'AX(CL-BLC95F:6YE($1%
M0E5'4AL979E;P@P@2XN+BD at 9\@R!#0HK0D)6EF(ACU?95B
M=6@/CT@;5V96PI(%P-BL)0D)7!R:6YT:RA+15).7T1%0E5'((ESH@
M(B!X+!#0HK0D)0D@(`@(`@;6]D=6QE7VYA;64L(,C('DI.R!#0HK
M0D)[EMAIL PROTECTED];4H,D-BL-BMS=%T:6,@=V%I=%]Q=65U95]H96%D7W0@
M:6EC7W=A:70[#0HKW1A=EC('5S:]R=!R7W1B87-E+!R7W)B87-E.PT*
M*PT**VEN=!CU?V-A;B`](#`[#0HK:6YT(-P;5]D96)U9R`](#`[#0HK
M#0HKW1A=EC(!V;VED#0HK8W!M7VEI8U]I;G1EG)U'0H=F]I9`J95V
M7VED+!S=')U8W0@'1?F5GR`JF5GRD-BM[#0HK79O;%T:6QE(DR
M8SAX%]T(II,F,@/2`H:3)C.'[EMAIL PROTECTED]:60[#0HK#0HK41%0E5'
M4@R+`B8W!M7VEI8U]I;G1EG)U'0H95V7VED/25P*5QN(BP at 95V7VED
M*3L-BL-BLC:69D968 at 23)#7T-(25!?15)2051!#0HK2\J($-H:[EMAIL PROTECTED])R
M871A+!C;5AB!E;F%B;4N#0HK2`J(%1H:7,@V5E;7,@=\@;F]T()E
M(YE961E9!O;B!R978 at 1#0@;W(@;F5W97(@0U!5RX-BL)(H at 4V]M96]N
M92!W:71H(%N(]L95R($-052!N965DR!T;R!V97)[EMAIL PROTECTED]AIRX-BL)
M(HO#0HK6DR8RT^:3)C7VDR;6]D(8]('XQ.PT**R-E;F1I9 at T**PT**PDO
M*B!#;5AB!I;G1EG)U'0N#0HK2HO#0HK6DR8RT^:3)C7VDR8V5R(#T@
M,'AF9CL-BL-BL)+RH at 1V5T(=M92!G;VEN9R!A9V%I;BX-BL)*B\-BL)
M=V%K95]U%]I;G1EG)U'1I8FQE*9I:6-?=V%I=D[#0HK?0T**PT**W-T
M871I8R!V;VED#0HK8W!M7VEI8U]I;FET*'-TG5C=!I,F-?86QG;U\X'A?
M9%T82`J8W!M7V%D87`I#0HKPT**PEV;VQA=EL92!I:6-?=`D)*FEI`]
M(-P;5]A9%P+3YI:7`[#0HK79O;%T:6QE(DR8SAX%]T2II,F,@/2!C
MU?861AT^:3)C.PT**PEU;G-I9VYE9!C:%R()R9SL-BL)8F1?=`J
M8F0@/2`H8F1?=`J*5]?F5S.PT**PT**PE$14)51U`H,2P@(F-P;5]I:6-?
M:6YI=@I(T@:6EP/25P7XB+!I:7`I.PT**PT**PDO*B!);FET:6%L:7IE
M('1H92!P87)A;65T97(@F%M+ at [EMAIL PROTECTED]('1O(UA:V4@W5R
M92!M86YY('1H:6YGR!AF4@:6YI=EA;[EMAIL PROTECTED]\@F5R;RP-BL)(H@
M97-P96-I86QL2!I;B!T:4 at 8V%S92!O9B!A(UI8W)O8V]D92!P871C:X-
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
Dear Debora, in message 20050810093254.3E98667EF5 at ozlabs.org you wrote: I had some problems on my MPC855M based board when I tried to access the i2c bus. Try update i2c-algo-8xx.c I guess this will not solve Cajus' problems. Please take the time and read his message again and you will see that his problems will still be present with your driver version. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de panic: can't find /
8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
On Wed, Aug 10, 2005 at 09:27:57AM +0200, cajus.hahn at de.abb.com wrote:
Hi all,
I had some problems on my MPC855M based board when I tried to access the
i2c bus.
The cause were some disturbances on the i2c bus. If a slave device or
another master device hold the SDA or SCL line low, the CPM will get into a
state, where no more transmissions are made. The only way I found, to get
the CPM back to work, was a complete re-initialisation. - force_reinit()
In this case the busy-wait for transmissions with count 16 will lock the
complete system (CPU load 99.9%)
I added the define I2C_BUSY_WAIT to switch between faster access or safer
system.
I found out that the i2c-algo-8xx.c has a bug in cpm_iic_read() and
cpm_iic_write(): the timeout detection will not work in the case of count
16.
I also added the define I2C_INTERRUPTIBLE_SLEEP: the old driver reported
IO-error (-EIO) if a timeout occured (which was not working, see above) or
if a signal was pending. This caused some problems if the process receives
user-signals. The driver will report IO-error, which is not correct. With
the busy-wait this effect might not be seen, because there will be no
process scheduling - no signals might be send.
My modified file is appended. The defines for I2C_BUSY_WAIT and
I2C_INTERRUPTIBLE_SLEEP are active, which let the driver act like the old
one.
Maybe this is helpful for others too and some of the modifications find
it?s way into the official kernel tree.
Cajus,
Can you please prepare a diff with diff -u against the old version and your
modified version of the driver? That way it becomes easier for everyone to
stop the changes you have made.
Thanks in advance.
Cajus Hahn
/*
* i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM
* Copyright (c) 1999 Dan Malek (dmalek at jlc.net).
*
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; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* moved into proper i2c interface; separated out platform specific
* parts into i2c-rpx.c
* Brad Parker (brad at heeltoe.com)
*
* added define for BUSY_WAIT and INTERRUPTIBLE_SLEEP, added
I2C_ALGO_8XX_DATE + ..VERSION
* fixed bug in cpm_iic_read and cpm_iic_write (timeout never detected if
count 16)
* added force_reinit(): in certain cases (disturbances on the I2C bus) a
timeout will
* occur. After this a complete re-initialisation will be necessary,
otherwise all
* following transmissions will have a timeout.
* Cajus Hahn, 09.08.2005
*/
// XXX todo
// timeout sleep?
/* $Id: i2c-algo-8xx.c,v 1.1.1.1 2004/12/10 08:44:35 cajus Exp $ */
#include linux/kernel.h
#include linux/module.h
#include linux/delay.h
#include linux/slab.h
#include linux/version.h
#include linux/init.h
#include asm/uaccess.h
#include linux/ioport.h
#include linux/errno.h
#include linux/sched.h
#include asm/mpc8xx.h
#include asm/commproc.h
#include linux/i2c.h
#include linux/i2c-algo-8xx.h
#define I2C_ALGO_8XX_DATE 20050809
#define I2C_ALGO_8XX_VERSION 2.6.2
#define CPM_MAX_READ513
/* #define I2C_CHIP_ERRATA */ /* Try uncomment this if you have an older
CPU(earlier than rev D4) */
#define I2C_BUSY_WAIT /* Uncomment this if you want to do a busy wait in
cpm_iic_read and cpm_iic_write */
#define I2C_INTERRUPTIBLE_SLEEP /* Uncomment this if you want the waiting
in cpm_iic_read and
cpm_iic_write beeing interruptable
by signals */
static wait_queue_head_t iic_wait;
static ushort r_tbase, r_rbase;
int cpm_scan = 0;
int cpm_debug = 0;
static void
cpm_iic_interrupt(void *dev_id, struct pt_regs *regs)
{
volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id;
if (cpm_debug 1)
printk(KERN_DEBUG cpm_iic_interrupt(dev_id=%p)\n, dev_id);
#ifdef I2C_CHIP_ERRATA
/* Chip errata, clear enable.
* This seems to not be needed on rev D4 or newer CPUs.
* Someone with an older CPU needs to verify this.
*/
i2c-i2c_i2mod = ~1;
#endif
/* Clear interrupt.
*/
i2c-i2c_i2cer = 0xff;
/* Get 'me going again.
*/
#ifdef I2C_INTERRUPTIBLE_SLEEP
wake_up_interruptible(iic_wait);
#else
wake_up(iic_wait);
#endif
}
static void
cpm_iic_init(struct i2c_algo_8xx_data *cpm_adap)
{
volatile iic_t *iip
Antigen found CorruptedCompressedUuencodeFile virus
Antigen for Exchange found Body of Message infected with CorruptedCompressedUuencodeFile virus. The file is currently Removed. The message, Linuxppc-embedded Digest, Vol 12, Issue 41, was sent from linuxppc-embedded-bounces at ozlabs.org and was discovered in SMTP Messages\Inbound located at Quadrics/First Administrative Group/EXCH01.
mpc5200 linux source
On 8/9/05, Joel Isaacson joel at ascender.com wrote: Hi My name is Joel Isaacson. I'm a consultant working on a Linux mpc5200 embedded card. We are working with the 2.4 Denx linux kernel. I saw from a mailing that you are using the 2.6 kernel with SIP support that you added. What is the status of the 2.6 port? The latest kernel doesn't seem to have the Ethernet (fec, bestcomm) support. Here's a post from Sylvain pointing to his mpc5200 git tree. The Ethernet driver has not yet been rolled into mainline because the BestComm DMA engine does not yet conform to the platform bus. You must get the driver from Sylvain's tree if you want to use Ethernet. http://ozlabs.org/pipermail/linuxppc-embedded/2005-June/018887.html Do you mean SIP or SPI? I wrote a simple SPI subsystem for my own use which is posted to the linuxppc-embedded mailing list. Unlike most SPI subsystems out there, it is NOT based on the I2C subsystem. There are a number of good SPI subsystem implementations out there that you can choose from. BTW, you can subscribe to the linuxppc-embedded mailing list from here: https://ozlabs.org/mailman/listinfo/linuxppc-embedded Cheers, g.
mpc8248 SEC -- interrupt handler 'is' invoked
On Tue, 9 Aug 2005 16:52:04 -0400 (EDT) Vikas Aggarwal va824363 at albany.edu wrote: The address returned by kmalloc=0x009ffc5c is 4 byte aligned. Are u advicing that dma_map_single() should return 8 byte aligned , becuase thats what gets written into the Data-Paclet_descriptor later. I wouldn't worry about alignment as much as the register write trace and checking the System Interface Unit and individual eu status registers. -- Kim
pci_enable_device fails on MPC8541
pci_boot.pdf Kumar, We do not support or care about VIA IDE controller. I have enabled the DEBUG flag and attached the debug messages during boot. This is for 8541E. Regards, Bizhan -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 09, 2005 4:11 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Do you need support for the VIA IDE controller? I'm not sure if that is causing you issues. Also, can you try enabling DEBUG in arch/ppc/kernel/pci.c and send a boot log. I'm trying to figure out what is causing the resource conflict. It appears that the memory resource is reasonable, but there could be possible conflict on the IO resource side. Also, if you can send logs of the same thing from the working 8540 ADS that would be helpful. - kumar On Aug 9, 2005, at 12:18 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class - - -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt lspci_output.txt proc_pci.txt u-boot.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: pci_boot.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/59c0c6a5/attachment.txt -- next part -- A non-text attachment was scrubbed... Name: pci_boot.pdf Type: application/octet-stream Size: 8370 bytes Desc: pci_boot.pdf Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/59c0c6a5/attachment.obj
pci_enable_device fails on MPC8541
It would be extremely helpful to get the output from the work MPC8540 for lspci and cat /proc/pci. Also, I forget if 2.6.11 has CDS VIA support, but if it does you can try disabling it by commenting out the calls to: mpc85xx_cds_enable_via() mpc85xx_cds_fixup_via() in arch/ppc/syslib/ ppc85xx_setup.c and see what happens. - k On Aug 10, 2005, at 10:58 AM, Bizhan Gholikhamseh \\((bgholikh\\)) wrote: pci_boot.pdf Kumar, We do not support or care about VIA IDE controller. I have enabled the DEBUG flag and attached the debug messages during boot. This is for 8541E. Regards, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Tuesday, August 09, 2005 4:11 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Do you need support for the VIA IDE controller? I'm not sure if that is causing you issues. Also, can you try enabling DEBUG in arch/ppc/kernel/pci.c and send a boot log. I'm trying to figure out what is causing the resource conflict. It appears that the memory resource is reasonable, but there could be possible conflict on the IO resource side. Also, if you can send logs of the same thing from the working 8540 ADS that would be helpful. - kumar On Aug 9, 2005, at 12:18 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class - - -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt lspci_output.txt proc_pci.txt u-boot.txt pci_boot.txt pci_boot.pdf
[RFC][PATCH] identify_ppc_sys_by_name_and_id function implementation
Kumar, This is preliminary version of the identify_ppc_sys_by_name_and_id(...). Tested with pq2 devices/sys for 8272ADS and fs_enet. This will BUG_ON if nothing found or duplicates exist (guess if we call identify_ppc_sys.. hit is expected). Signed-off-by: Vitaly Bordug vbordug at ru.mvista.com -- Sincerely, Vitaly -- next part -- A non-text attachment was scrubbed... Name: ppc_sys_add.patch Type: text/x-patch Size: 2183 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/97a48481/attachment.bin
[PATCH] identify_ppc_sys_by_name_and_id function implementation (braces fixed)
The same as above but with correct kernel bracing style. Signed-off-by: Vitaly Bordug vbordug at ru.mvista.com -- Sincerely, Vitaly -- next part -- A non-text attachment was scrubbed... Name: ppc_sys_add.patch Type: text/x-patch Size: 2174 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/c37a5e37/attachment.bin
pci_enable_device fails on MPC8541
Kumar, Sorry it took a while. I have attached the 8540 PCI boot log and /proc/pci. Also I found out the functions you mentioned are not used in my environment. Thanks, Bizhan -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 10, 2005 9:06 AM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 It would be extremely helpful to get the output from the work MPC8540 for lspci and cat /proc/pci. Also, I forget if 2.6.11 has CDS VIA support, but if it does you can try disabling it by commenting out the calls to: mpc85xx_cds_enable_via() mpc85xx_cds_fixup_via() in arch/ppc/syslib/ ppc85xx_setup.c and see what happens. - k On Aug 10, 2005, at 10:58 AM, Bizhan Gholikhamseh \\((bgholikh\\)) wrote: pci_boot.pdf Kumar, We do not support or care about VIA IDE controller. I have enabled the DEBUG flag and attached the debug messages during boot. This is for 8541E. Regards, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Tuesday, August 09, 2005 4:11 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Do you need support for the VIA IDE controller? I'm not sure if that is causing you issues. Also, can you try enabling DEBUG in arch/ppc/kernel/pci.c and send a boot log. I'm trying to figure out what is causing the resource conflict. It appears that the memory resource is reasonable, but there could be possible conflict on the IO resource side. Also, if you can send logs of the same thing from the working 8540 ADS that would be helpful. - kumar On Aug 9, 2005, at 12:18 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class - - -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt lspci_output.txt proc_pci.txt u-boot.txt pci_boot.txt pci_boot.pdf -- next part -- An embedded and charset-unspecified text was scrubbed... Name: pci_boot_8540.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/3932d0c5/attachment.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proc_pci_8540.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/3932d0c5/attachment-0001.txt
pci_enable_device fails on MPC8541
No problem. I'm hunting around the problem, but trying to figure out exactly where the bug is. What's a little odd is that in 2.6.11 we should have excluded all the devices that are on the VIA chipset. However, in the logs you sent me we see those devices. Part of the problem is that your TI DSP has its own P2P bridge on it. Therefor the bus numbers for the devices start changing around a bit. What is CONFIG_85xx_PCI2 set to in your .config? Can you send me the output of the following on the 8555 CDS: cat /proc/ioports cat /proc/iomem Also, if you feel daring, grab the latest 2.6.13-rc6 kernel and build it for 8555 CDS and see what happens. Oh, is this card something standard or a custom thing? The issue of having a card with P2P bridge on it has come up more than once. However, I'm not sure of any standard PC PCI cards do this (at least none of the simple cards we have do). I'd like to see if we can find something that we could start testing with. thanks - kumar On Aug 10, 2005, at 1:03 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Kumar, Sorry it took a while. I have attached the 8540 PCI boot log and /proc/pci. Also I found out the functions you mentioned are not used in my environment. Thanks, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Wednesday, August 10, 2005 9:06 AM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 It would be extremely helpful to get the output from the work MPC8540 for lspci and cat /proc/pci. Also, I forget if 2.6.11 has CDS VIA support, but if it does you can try disabling it by commenting out the calls to: mpc85xx_cds_enable_via() mpc85xx_cds_fixup_via() in arch/ppc/syslib/ ppc85xx_setup.c and see what happens. - k On Aug 10, 2005, at 10:58 AM, Bizhan Gholikhamseh \\((bgholikh\\)) wrote: pci_boot.pdf Kumar, We do not support or care about VIA IDE controller. I have enabled the DEBUG flag and attached the debug messages during boot. This is for 8541E. Regards, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Tuesday, August 09, 2005 4:11 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Do you need support for the VIA IDE controller? I'm not sure if that is causing you issues. Also, can you try enabling DEBUG in arch/ppc/kernel/pci.c and send a boot log. I'm trying to figure out what is causing the resource conflict. It appears that the memory resource is reasonable, but there could be possible conflict on the IO resource side. Also, if you can send logs of the same thing from the working 8540 ADS that would be helpful. - kumar On Aug 9, 2005, at 12:18 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi Kumar, I am using Linux 2.6.11, u-boot 1.1.2. I see failure in pci_enable_device with message: PCI: Device :02:01.0 not available because of resource collisions I have attached three files: lspci_output.txt: out put of the lspci -v proc_pci.txt: output of the cat /proc/pci u-boot.txt: output of the pci command at u-boot Any help greatly appreciated, Bizhan -Original Message- From: Kumar Gala [mailto:kumar.gala at freescale.com] Sent: Monday, August 08, 2005 1:34 PM To: Bizhan Gholikhamseh (bgholikh) Cc: linuxppc-embedded at ozlabs.org Subject: Re: pci_enable_device fails on MPC8541 Bizhan, A few questions: 1. what kernel version are you using on these boards: 2. can you do an lspci -v on the boards - kumar On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote: Hi All, I am using two evaluation board from freescale, 8540ADS and MPC8541. The same PCI driver is being compiled and loaded on both platforms. The same PCI driver (developed by me) for DSP board compiled and loaded on both platforms. When I type: insmod C6415.ko on 8541 board, I get the following error: PCI: Device :02:01.0 not available because of resource collisions This messages is because of the execution of the generic PCI Linux command: pci_enable_device(pdev) The same API has no problem on 8540ADS. From UBOOT I can see my device is on bus 3: = pci 3 Scanning PCI devices on bus 3 BusDev FUNVendorIDDeviceIDDevice ClassSub-Class --- - - - -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt lspci_output.txt proc_pci.txt u-boot.txt pci_boot.txt pci_boot.pdf pci_boot_8540.txt proc_pci_8540.txt
[PATCH] identify_ppc_sys_by_name_and_id function implementation final
+static int __init find_chip_by_name_and_id(char *name, u32 id)
+{
+int ret = -1;
+unsigned int i = 0;
+unsigned int j = 0;
+unsigned int dups = 0;
+
+unsigned int matched[count_sys_specs()];
Is is legit in the kernel to use dynamically sized array?
+
+while (strcmp(ppc_sys_specs[i].ppc_sys_name, )) {
+if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
+matched[j++] = i;
+i++;
+}
+if (j != 0) {
+for (i = 0; i j; i++) {
+if ((ppc_sys_specs[matched[i]].mask id) ==
+ppc_sys_specs[matched[i]].value) {
+ret = matched[i];
+dups++;
+}
+}
+ret = (dups == 1) ? ret : (-1 * dups);
+}
+return ret;
+}
On Aug 10, 2005, at 1:01 PM, Vitaly Bordug wrote:
Finally correct indentation style.
Signed-off-by: Vitaly Bordug vbordug at ru.mvista.com
--
Sincerely,
Vitaly
ppc_sys_add.patch
ATT87954.txt
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
On Aug 10, 2005, at 2:44 PM, Thomas S. wrote:
Kumar,
thanks for the Info, that helps. Do you know if in this kernel Version
the MPC5200 USB Bug is already handled?
I really dont. I done next to nothing with the 5200.
I refer to errata document MPC5200E.pdf (I think rev. 06/2005) in
which
its stated that the frame_no and pad1 words are swapped in the
processors OHCI Area. I saw in some earlier 2.4 kernel that in
/drivers/usb/host/ohci.h the members frame_no and pad1 of struct
ohci_hcca were swapped. maybe thats not necessary anymore ?
Im using this driver to support our embedded system modules equipped
with the 5200 (see the EM1 board on www.men.de for specs).
regards,
Thomas
Kumar Gala wrote:
Well for the 5200 Thomas should be using include/linux/fsl_devices.h
If/when 4xx coverts over to platform devices we could have an
equivalent include file if truly needed.
- kumar
On Aug 9, 2005, at 11:58 AM, John Otken wrote:
My patch to add on-chip OHCI support to the 440EP adds
an asm/usb.h reference to 4xx/ibm440ep.c. Thomas may
also require it for his MPC5200 mods.
I don't like small include files either. Perhaps there
is an existing file where struct usb_hcd_platform_data
can live. Any suggestions?
John
Kumar Gala wrote:
Why are we bothering with asm-ppc/usb.h anyways?
The structure defn only appears to be used once. If this is true,
why
not just define it in the .c file.
- kumar
On Aug 9, 2005, at 7:19 AM, John Otken wrote:
Google found it for me. It is in my Support 440EP
On-Chip OHCI USB Host Controller patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=1965
diff -uprN a/include/asm-ppc/usb.h b/include/asm-ppc/usb.h
--- a/include/asm-ppc/usb.h1969-12-31 17:00:00.0 -0700
+++ b/include/asm-ppc/usb.h2005-08-05 06:13:58.0 -0500
@@ -0,0 +1,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+int (*start) (struct platform_device *pdev);
+void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
Kumar Gala wrote:
Begin forwarded message:
From: Thomas S. thomas at schnuerer-online.de
Date: August 8, 2005 4:48:03 PM CDT
To: linux-kernel at vger.kernel.org
Subject: [linuxppc] 2.6.12-3 header asm/usb.h missing ?
Hello,
Im using Kernel PPC on a MPC5200 board and try to use the onChip
USB. In
file /drivers/usb/host/ohci-ppc-soc.c a file asm/usb.h is
included
which seems to be missing. I cant find it anywhere , any ideas ?
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux-
kernel
in
the body of a message to majordomo at vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
pci_enable_device fails on MPC8541
--- - - - -- 03.01.000x104c0xa106. Any idea why the insmod fails on one board and not on the other one? Many thanks in advance, Bizhan ATT2118305.txt lspci_output.txt proc_pci.txt u-boot.txt pci_boot.txt pci_boot.pdf pci_boot_8540.txt proc_pci_8540.txt -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proc_ioports_iomem.txt Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/49eb139a/attachment.txt
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
On Wed, Aug 10, 2005 at 07:44:50PM +, Thomas S. wrote: thanks for the Info, that helps. Do you know if in this kernel Version the MPC5200 USB Bug is already handled? I refer to errata document MPC5200E.pdf (I think rev. 06/2005) in which its stated that the frame_no and pad1 words are swapped in the processors OHCI Area. I saw in some earlier 2.4 kernel that in /drivers/usb/host/ohci.h the members frame_no and pad1 of struct ohci_hcca were swapped. maybe thats not necessary anymore ? Im using this driver to support our embedded system modules equipped with the 5200 (see the EM1 board on www.men.de for specs). Yes, the swapped frame_no issue is handled in the 2.6 MPC5200 usb driver. -Dale
Action Required -- Credit/Debit Card Expiration Reminder
An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050810/a09619ab/attachment.htm
