* Re: CLOCK_TICK_RATE
From: Andreas Schwab @ 2005-08-11 16:14 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859421@ismail.innsys.innovsys.com>
"Rune Torgersen" <runet@innovsys.com> writes:
> Hi
>
> I have found that I need to set CLOCK_TICK_RATE (currently defined in
> include/asm-ppc/timex.h) to something else.
I can't find any use of CLOCK_TICK_RATE in the kernel that is relevant for
ppc.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* GDB backtrace and signal trampolines
From: Hollis Blanchard @ 2005-08-11 15:54 UTC (permalink / raw)
To: PPC64-dev List, Linux PPC Dev
GDB 6.3 contains this code in ppc-linux-tdep.c:
static const struct frame_unwind *
ppc_linux_sigtramp_sniffer (struct frame_info *next_frame)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch
(next_frame));
if (frame_pc_unwind (next_frame)
> frame_unwind_register_unsigned (next_frame, SP_REGNUM))
/* Assume anything that is vaguely on the stack is a signal
trampoline. */
return &ppc_linux_sigtramp_unwind;
else
return NULL;
}
Essentially it says that any time the program counter is above the
stack pointer, we must be in a signal trampoline, and so GDB proceeds
to grope about for a struct rt_sigframe on the stack.
This is not a good assumption. I'm using a GDB stub to debug Xen, and
as it so happens, the Xen stack is below the Xen text. That means that
the above test always triggers, but of course there is no rt_sigframe
on the stack, and my backtrace runs away.
Would it make sense to limit the test to within a few hundred bytes of
the stack pointer? Or some better way to detect that the PC is in a
signal trampoline?
(Also, how can I test backtraces within a signal trampoline? I've
single-stepped my way into and out of a signal hander, and never saw
the PC inside the stack.)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] cpm_uart: added missed spinlock initialization
From: Vitaly Bordug @ 2005-08-11 15:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
The lack of spin_lock_init causes badness in the preempt configuration.
The fix is trivial.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: cpm_uart_spinlock.patch --]
[-- Type: text/x-patch, Size: 440 bytes --]
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1045,6 +1045,7 @@ static int __init cpm_uart_console_setup
port =
(struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
pinfo = (struct uart_cpm_port *)port;
+ spin_lock_init(&port->lock);
pinfo->flags |= FLAG_CONSOLE;
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-11 15:25 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list
In-Reply-To: <20050811053032.GF5665@dmt.cnet>
Marcelo Tosatti wrote:
> On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>
>>+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?
>
>
> kmalloc() is certainly safer - why not use it?
Practically , version with kmalloc works, but setup_arch and thus this
function is called before mem_init, so I just wonder if kmalloc can
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
does) just for the temporary buffer.
But it's the only _right_ way (or I 've missed something) - sure I'll
follow it.
--
Sincerely,
Vitaly
^ permalink raw reply
* CLOCK_TICK_RATE
From: Rune Torgersen @ 2005-08-11 15:13 UTC (permalink / raw)
To: linuxppc-dev
Hi
I have found that I need to set CLOCK_TICK_RATE (currently defined in
include/asm-ppc/timex.h) to something else.
Right now it is set to the PC timer clock value (1193180Hz). I need to
set it to the frequency of my decrementer instead (busfreq/4)
Right now the value of theis define means the wall-clock time on ALL ppc
(and ppc64) systems that does not use the old I386 timer freqyuencly
(most all?) are using the wrong values.
How can I change this to be platform dependant?=20
The other problem is that it has to be hardcoded on compile time, but
I'm not going to worry to much about that.
^ permalink raw reply
* RE: copy_from_user problem
From: T Michael Turney @ 2005-08-11 14:29 UTC (permalink / raw)
To: murahari, linuxppc-dev
In-Reply-To: <0IL100L2IEO6NG@ms13.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]
Samsung Enterprise Portal mySingleMurahari,
I always start simple and work up to the harder things. Try to access a
single
long word in the ioctl, e.g.,
int
chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd, unsigned
long arg)
{
int ret = 0;
unsigned int userdata;
switch(cmd)
{
case IOCTL_WIN_DEBUG_READ_CODE:
{
ret = get_user(userdata, (unsigned int *)arg);
......
}
}
}
The two O'Reilly books, Linux Device Drivers and Understanding the Linux
Kernel are also good
references for how to use the get_user and copy_from_user macros.
Hope this helps.
Cheers,
T.mike
-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of V MURAHARI
Sent: Wednesday, August 10, 2005 7:53 PM
To: linuxppc-dev@ozlabs.org
Subject: copy_from_user problem
Hello,
I am working on a character driver for reading and writing the registers
to FPGA in our system.
I am using driver ioctl to read/write to these registers of FPGA. As the
function call to the ioctl is being made, the printk trace shows that the
call goes to switch->copy_from_user. As soon as the call is made to
copy_from_user, the kernel crashes
Can someone help me with this problem?
****************************************************************************
***********************
Unhandled kernel unaligned access in
unaligned.c::emulate_load_store_insn, line 483
:
$0 : 00000000 10001f00 8fbf0034 02a01021 801157a0 8fe8e000 10001f00
ffff00ff
$8 : 8fe8ffe0 00001f00 00000000 00000003 74652053 8fe9fed8 0000000a
50434942
$16: 10001f01 00000001 801157a0 0000000f 8fe8fee8 00000104 00000000
0000000f
$24: 00000000 2ac0fdb0 8fe8e000 8fe8fe38 00000001
8012010c
Hi : 00000000
Lo : 00000000
epc : 8011f774 Tainted: GF
Status: 10001f02
Cause : 00800014
Process rsgbm (pid: 317, stackpage=8fe8e000)
Stack: 802d920a 0000000a 10001f01 0000003c 10001f01 0000003c 8012010c
80120104 caa8f356 8fe82008 8fe82000 0000000f 00000000 7fff7d00 7fff7d00
0000c001 00000003 10012808 ffffffff caa8e548 00004000 8fe9e272 00000150
7fff7d00 ffffffea 00000000 00000240 8fe82000 00000000 00000001 00000001
7ebff310 00000000 0000000f 8fef24e0 00000004 7ebff3e8 00000000 0000002e
80159c6c ...
Call Trace: [<8012010c>] [<80120104>] [<caa8f356>] [<caa8e548>]
[<80159c6c>]
[<8010a5c4>] [<80271dc4>]
Code: 8c820004 24110001 ac430000 <ac620004> ac800000 ac800004 ac800000
ac800004
8f820004
Unit Fault Handler !!! (INDEX=10)
****************************************************************************
**********************
int
chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd,
unsigned long arg)
{
int ret = 0;
n2_debug_rw_reg *dw;
switch(cmd)
{
case IOCTL_WIN_DEBUG_READ_CODE:
{
n2_debug_rw_reg test;
printk("%s %d\n", current->comm, current->pid);
printk("%lx\n", arg);
copy_from_user(&test, (n2_debug_rw_reg*)arg,
sizeof(n2_debug_rw_reg));
printk("%lx %lx\n", ((n2_debug_rw_reg*)arg)->data,
((n2_debug_rw_reg*)arg)->
addr);
}
}
}
Thanks & Regards,
--Murahari
[-- Attachment #2: Type: text/html, Size: 7237 bytes --]
^ permalink raw reply
* where to get new BestComm API
From: Nuguru Susheel @ 2005-08-11 17:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Why do we need Bestcomm API new version for MPC5200 Rev B processor
Where can I get it from ???
Thanks a lot
^ permalink raw reply
* RE: Mpc5200 and ISP1106/1107 USB transceivers
From: Zeitler, Nathan @ 2005-08-11 13:27 UTC (permalink / raw)
To: linuxppc-embedded
IA0KID4gVXJsOiBodHRwOi8vb3psYWJzLm9yZy9waXBlcm1haWwvbGludXhwcGMtZW1iZWRkZWQv
YXR0YWNobWVudHMvMjAwNTA4MDUvYTJhYTBkNzgvYXR0YWNobWVudC0wMDAxLmVtbA0KDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VlbXMgdGhhdCBQaGlsaXBzIGhhcyBwdXQg
b3V0IGFuIGVycmF0YSBub3QgdG9vIGxvbmcgYWdvIGZvciB0aGlzIA0KY2hpcCB3aGljaCBpc24n
dCBpbiBhbnkgcHVibGljIGVycmF0YSBkb2N1bWVudCB0aGF0IHdlIGNvdWxkIGZpbmQuICANCkhl
cmUncyBob3cgaXQgcmVhZHM6DQoNClByb2JsZW06IA0KV2l0aCB0aGUgSVNQMTEwNS82IHVzZWQg
YXMgYSBVbml2ZXJzYWwgU2VyaWFsIEJ1cyAoVVNCKSANCnRyYW5zY2VpdmVyIGluIGEgSG9zdCBD
b250cm9sbGVyIGFwcGxpY2F0aW9uLCB3aGVuIGEgbG93LXNwZWVkIA0KZGV2aWNlIGlzIGNvbm5l
Y3RlZCwgaXQgZG9lcyBub3QgZ2V0IGVudW1lcmF0ZWQuIEZ1bGwtc3BlZWQgDQpkZXZpY2VzLCBo
b3dldmVyLCBhcmUgcHJvcGVybHkgZW51bWVyYXRlZC4NCg0KV2hlbiBwaW4gT0VfTiBnb2VzIEhJ
R0gsIHRoZSBJU1AxMTA1LzYgbXVzdCBiZSBpbiByZWNlaXZlIA0KbW9kZSBhbmQgdGhlIERNIGxp
bmUgc2hvdWxkIGJlIGRldGVjdGVkIGFzIEhJR0ggYmVjYXVzZSBvZiANCnRoZSBwdWxsLXVwIHJl
c2lzdG9yIG9uIHRoZSBE4oiSIGxpbmUgaW4gdGhlIGNhc2Ugb2YgdGhlIGxvdy1zcGVlZCANCmRl
dmljZS4gQnV0IGluIHRoZSBJU1AxMTA1LzYsIHRoZSBE4oiSIGxpbmUgcmlzZXMgdmVyeSBzbG93
bHksIHRha2luZyANCmFsbW9zdCAzMCBtcy4gVGhpcyBhZmZlY3RzIGVudW1lcmF0aW9uLg0KDQpX
b3JrYXJvdW5kOg0KSW4gdGhlIElTUDExMDUsIHRoZSBwcm9ibGVtIGNhbiBiZSByZXNvbHZlZCBi
eSBPUmluZyBWTyB3aXRoIA0KT0VfTiB0byBwcm9kdWNlIFZPIHRvIHRoZSBJU1AxMTA1LiBUaGlz
IGlzIGFwcGxpY2FibGUgd2hlbiANCnRoZSBNT0RFIHBpbiBpcyBjb25maWd1cmVkIGFzIExPVzsg
c2luZ2xlLWVuZGVkIGlucHV0IGRhdGEgDQppbnRlcmZhY2UuIA0KDQpUaGlzIGNpcmN1aXQgd2ls
bCBlbnN1cmUgdGhhdCBWTyBpcyBoZWxkIEhJR0ggdGlsbCBPRV9OIGlzIEhJR0gsIA0KZW5zdXJp
bmcgdGhhdCB0aGUgY29tcGVuc2F0aW9uIGxvZ2ljIGlzIG5vdCB0dXJuZWQgb24uDQoNCkluIHRo
ZSBJU1AxMTA2LCB0aGlzIG11c3QgYmUgaW1wbGVtZW50ZWQgYnkgQU5EaW5nIE9FIA0KKGludmVy
dGVkIE9FX04pIHdpdGggVk1PIHRvIHByb2R1Y2UgVk1PIHRvIHRoZSBJU1AxMTA2Lg0KDQoNCk5h
dGhhbiBaZWl0bGVyDQpIYXJkd2FyZSBFbmdpbmVlcg0KT3BlbiBTeXN0ZW1zIEludGVybmF0aW9u
YWwsIEluYy4NCjM2MDAgSG9sbHkgTGFuZSBOb3J0aCwgU3VpdGUgNDANCk1pbm5lYXBvbGlzLCBN
TiA1NTQ0Ny0xMjg2DQpQaG9uZTogKDc2MykgNTUxLTA1NTkNCkZheDogICAgICg3NjMpNTUxLTA3
NTANCkVtYWlsOiAgbnplaXRsZXJAb3NpaS5jb20NCg==
^ permalink raw reply
* Re: copy_from_user problem
From: Clemens Koller @ 2005-08-11 11:02 UTC (permalink / raw)
To: murahari; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <0IL100L2IEO6NG@ms13.samsung.com>
Hi, Murahari!
> I am working on a character driver for reading and writing the registers to FPGA
> in our system.
You didn't tell much about your system.
But checkout the examples in the book "Linux Device Drivers, 3rd Edition".
(http://lwn.net/images/pdf/LDD3/)
which is worth buying, too!
You might be missing some simple __user casts for your data
structures you want to copy...
And you might need to ioremap the memory area of your fpga or whatever
you need to access.
> epc : 8011f774 Tainted: GF
^^^^^^^^^^^
And you might end up with less support here if you use a tainted Kernel.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Cajus Hahn @ 2005-08-11 7:42 UTC (permalink / raw)
To: linuxppc-embedded, cajus.hahn
Marcello,
my "old" version is from the linuxppc_2_4_devel CVS archive on www.denx.de:/cvsroot.
The i2c-algo-8xx.c there has the revision number 1.5.
Regards
Cajus
--- ../../i2c-algo-8xx.c 2005-08-10 16:19:09.000000000 +0200
+++ drivers/i2c/i2c-algo-8xx.c 2005-08-10 08:03:46.000000000 +0200
@@ -19,12 +19,19 @@
* moved into proper i2c interface; separated out platform specific
* parts into i2c-rpx.c
* Brad Parker (brad@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.7 2002/08/03 22:48:18 ac9410 Exp $ */
+/* $Id: i2c-algo-8xx.c,v 1.2 2005/08/10 06:03:46 cajus Exp $ */
#include <linux/kernel.h>
#include <linux/module.h>
@@ -43,8 +50,16 @@
#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_READ 513
/* #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. In a timeout case the CPU load will be 99.9% ! */
+#define I2C_INTERRUPTIBLE_SLEEP /* Uncomment this if you want the waiting in cpm_iic_read and
+ cpm_iic_write being interruptable by signals */
+
static wait_queue_head_t iic_wait;
static ushort r_tbase, r_rbase;
@@ -73,7 +88,11 @@
/* Get 'me going again.
*/
+#ifdef I2C_INTERRUPTIBLE_SLEEP
wake_up_interruptible(&iic_wait);
+#else
+ wake_up(&iic_wait);
+#endif
}
static void
@@ -201,20 +220,77 @@
static void force_close(struct i2c_algo_8xx_data *cpm)
{
volatile i2c8xx_t *i2c = cpm->i2c;
+
+ if (cpm_debug)
+ printk(KERN_DEBUG "force_close()");
+
if (cpm->reloc == 0) { /* micro code disabled */
volatile cpm8xx_t *cp = cpm->cp;
-
- if (cpm_debug) printk(KERN_DEBUG "force_close()\n");
cp->cp_cpcr =
mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_CLOSE_RXBD) |
CPM_CR_FLG;
while (cp->cp_cpcr & CPM_CR_FLG);
}
+
i2c->i2c_i2cmr = 0x00; /* Disable all interrupts */
i2c->i2c_i2cer = 0xff;
}
+static void force_reinit(struct i2c_algo_8xx_data *cpm)
+{
+ volatile iic_t *iip = cpm->iip;
+ volatile i2c8xx_t *i2c = cpm->i2c;
+ volatile cpm8xx_t *cp = cpm->cp;
+ unsigned char brg;
+ bd_t *bd = (bd_t *)__res;
+
+ // Disable interrupts.
+ i2c->i2c_i2cmr = 0;
+ i2c->i2c_i2cer = 0xff;
+ // Clear enable
+ i2c->i2c_i2mod &= ~1;
+
+ // Initialize the parameter ram.
+ iip->iic_rstate = 0;
+ iip->iic_rdp = 0;
+ iip->iic_rbptr = 0;
+ iip->iic_rbc = 0;
+ iip->iic_rxtmp = 0;
+ iip->iic_tstate = 0;
+ iip->iic_tdp = 0;
+ iip->iic_tbptr = 0;
+ iip->iic_tbc = 0;
+ iip->iic_txtmp = 0;
+ iip->iic_tbase = r_tbase;
+ iip->iic_rbase = r_rbase;
+ iip->iic_tfcr = SMC_EB;
+ iip->iic_rfcr = SMC_EB;
+ iip->iic_mrblr = CPM_MAX_READ;
+
+ if (cpm->reloc == 0)
+ {
+ cp->cp_cpcr = mk_cr_cmd(CPM_CR_CH_I2C, CPM_CR_INIT_TRX) | CPM_CR_FLG;
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ }
+ else
+ {
+ iip->iic_rbptr = iip->iic_rbase;
+ iip->iic_tbptr = iip->iic_tbase;
+ iip->iic_rstate = 0;
+ iip->iic_tstate = 0;
+ }
+
+ // Select an arbitrary address. Just make sure it is unique.
+ i2c->i2c_i2add = 0xfe;
+
+ // Make clock run at 60 KHz.
+ brg = (unsigned char) (bd->bi_intfreq/(32*2*60000) -3);
+ i2c->i2c_i2brg = brg;
+
+ i2c->i2c_i2mod = 0x00;
+ i2c->i2c_i2com = 0x01; /* Master mode */
+}
/* Read from IIC...
* abyte = address byte, with r/w flag already set
@@ -227,7 +303,7 @@
volatile cpm8xx_t *cp = cpm->cp;
volatile cbd_t *tbdf, *rbdf;
u_char *tb;
- unsigned long flags, tmo;
+ unsigned long flags, tmo, timedout;
if (count >= CPM_MAX_READ)
return -EINVAL;
@@ -269,7 +345,10 @@
rbdf->cbd_bufaddr = __pa(buf);
rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP| BD_SC_INTRPT;
+ timedout = 0;
+#ifdef I2C_BUSY_WAIT
if(count > 16){
+#endif
/* Chip bug, set enable here */
local_irq_save(flags);
i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
@@ -278,23 +357,40 @@
i2c->i2c_i2com |= 0x80; /* Begin transmission */
/* Wait for IIC transfer */
+#ifdef I2C_INTERRUPTIBLE_SLEEP
tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
+#else
+ tmo = sleep_on_timeout(&iic_wait,1*HZ);
+#endif
+ if(tmo == 0) timedout=1;
local_irq_restore(flags);
+#ifdef I2C_BUSY_WAIT
} else { /* busy wait for small transfers, its faster */
i2c->i2c_i2cmr = 0x00; /* Disable I2C interupts */
i2c->i2c_i2cer = 0xff;
i2c->i2c_i2mod |= 1; /* Enable */
i2c->i2c_i2com |= 0x80; /* Begin transmission */
tmo = jiffies + 1*HZ;
- while(!(i2c->i2c_i2cer & 0x11 || time_after(jiffies, tmo))); /* Busy wait, with a timeout */
+ while(!(i2c->i2c_i2cer & 0x11 || (timedout = time_after(jiffies, tmo)))); /* Busy wait, with a timeout */
}
+#endif
+ if(timedout)
+ {
+ printk(KERN_DEBUG "cpm_iic_read: timeout!\n");
+ force_reinit(cpm);
+ return -EIO;
+ }
+
+#ifdef I2C_INTERRUPTIBLE_SLEEP
+ if (signal_pending(current))
+ {
+ force_close(cpm);
+ if (cpm_debug)
+ printk(KERN_DEBUG "cpm_iic_read: signal_pending! \n");
+ return -EINTR;
+ }
+#endif
- if (signal_pending(current) || !tmo){
- force_close(cpm);
- if(cpm_debug)
- printk(KERN_DEBUG "IIC read: timeout!\n");
- return -EIO;
- }
#ifdef I2C_CHIP_ERRATA
/* Chip errata, clear enable. This is not needed on rev D4 CPUs.
Disabling I2C too early may cause too short stop condition */
@@ -359,7 +455,7 @@
volatile cpm8xx_t *cp = cpm->cp;
volatile cbd_t *tbdf;
u_char *tb;
- unsigned long flags, tmo;
+ unsigned long flags, tmo, timedout;
/* check for and use a microcode relocation patch */
if (cpm->reloc) {
@@ -385,7 +481,10 @@
tbdf[1].cbd_datlen = count;
tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP;
+ timedout = 0;
+#ifdef I2C_BUSY_WAIT
if(count > 16){
+#endif
/* Chip bug, set enable here */
local_irq_save(flags);
i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
@@ -394,23 +493,39 @@
i2c->i2c_i2com |= 0x80; /* Begin transmission */
/* Wait for IIC transfer */
+#ifdef I2C_INTERRUPTIBLE_SLEEP
tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
+#else
+ tmo = sleep_on_timeout(&iic_wait,1*HZ);
+#endif
+ if(tmo == 0) timedout=1;
local_irq_restore(flags);
+#ifdef I2C_BUSY_WAIT
} else { /* busy wait for small transfers, its faster */
i2c->i2c_i2cmr = 0x00; /* Disable I2C interupts */
i2c->i2c_i2cer = 0xff;
i2c->i2c_i2mod |= 1; /* Enable */
i2c->i2c_i2com |= 0x80; /* Begin transmission */
tmo = jiffies + 1*HZ;
- while(!(i2c->i2c_i2cer & 0x12 || time_after(jiffies, tmo))); /* Busy wait, with a timeout */
- }
-
- if (signal_pending(current) || !tmo){
- force_close(cpm);
- if(cpm_debug && !tmo)
- printk(KERN_DEBUG "IIC write: timeout!\n");
- return -EIO;
+ while(!(i2c->i2c_i2cer & 0x12 || (timedout = time_after(jiffies, tmo)))); /* Busy wait, with a timeout */
}
+#endif
+ if(timedout)
+ {
+ printk(KERN_DEBUG "cpm_iic_write: timeout!\n");
+ force_reinit(cpm);
+ return -EIO;
+ }
+
+#ifdef I2C_INTERRUPTIBLE_SLEEP
+ if (signal_pending(current))
+ {
+ force_close(cpm);
+ if (cpm_debug)
+ printk(KERN_DEBUG "cpm_iic_write: signal_pending! \n");
+ return -EINTR;
+ }
+#endif
#if I2C_CHIP_ERRATA
/* Chip errata, clear enable. This is not needed on rev D4 CPUs.
@@ -495,7 +610,11 @@
if (cpm_debug > 1) printk(KERN_DEBUG "about to sleep\n");
/* wait for IIC transfer */
+#ifdef I2C_INTERRUPTIBLE_SLEEP
tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ);
+#else
+ tmo = sleep_on_timeout(&iic_wait,1*HZ);
+#endif
local_irq_restore(flags);
#ifdef I2C_CHIP_ERRATA
@@ -658,7 +777,7 @@
int __init i2c_algo_8xx_init (void)
{
- printk(KERN_INFO "i2c-algo-8xx.o: i2c mpc8xx algorithm module version %s (%s)\n", I2C_VERSION, I2C_DATE);
+ printk(KERN_INFO "i2c-algo-8xx.o: i2c mpc8xx algorithm module version %s (%s)\n", I2C_ALGO_8XX_VERSION, I2C_ALGO_8XX_DATE);
return 0;
}
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Marcelo Tosatti @ 2005-08-11 5:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <4BA092C9-1517-416E-9C98-90F9D8F41857@freescale.com>
On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
> +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?
kmalloc() is certainly safer - why not use it?
> +
> + 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@ru.mvista.com>
> >> >--
> >Sincerely,
> >Vitaly
> >
> ><ppc_sys_add.patch>
> ><ATT87954.txt>
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* I2C (slave mode) with MPC8245
From: Daniel Ann @ 2005-08-11 5:16 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
I've been toddling with the i2c codes at the moment, and it seems that
if I make 8245 as master, it communicates perfectly well with my other
device.
However, getting 8245 to act as slave is proving to be a challenge.
I'm currently working with kernel 2.6.12.3 and finding pieces of code
that should deal with slave mode transfer is missing from i2c-mpc.c.
Is there any place I could get it ? or if I have to do it, may be an
advice or suggestion would be appreciated.
Thanks.
--=20
Daniel
^ permalink raw reply
* [PATCH] ppc32: Add ppc_sys descriptions for PowerQUICC II devices
From: Kumar Gala @ 2005-08-11 4:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
Added ppc_sys device and system definitions for PowerQUICC II devices.
This will allow drivers for PQ2 to be proper platform device drivers.
Which can be shared on PQ3 processors with the same peripherals.
Signed-off-by: Matt McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 31937ee5383892a5236505c8bbad8715fbfbfadf
tree 30c204867add0d919be4dc7fc5e02e749cea34d2
parent b53ff9c2e3f62d23f4dd9ca3e312968d1466c188
author Kumar K. Gala <kumar.gala@freescale.com> Wed, 10 Aug 2005 23:14:26 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 10 Aug 2005 23:14:26 -0500
arch/ppc/kernel/setup.c | 8 +
arch/ppc/syslib/Makefile | 3
arch/ppc/syslib/pq2_devices.c | 389 +++++++++++++++++++++++++++++++++++++++++
arch/ppc/syslib/pq2_sys.c | 200 +++++++++++++++++++++
include/asm-ppc/irq.h | 1
include/asm-ppc/mpc8260.h | 18 ++
include/asm-ppc/ppc_sys.h | 4
7 files changed, 619 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -41,7 +41,11 @@
#include <asm/xmon.h>
#include <asm/ocp.h>
-#if defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_MPC10X_BRIDGE)
+#define USES_PPC_SYS (defined(CONFIG_85xx) || defined(CONFIG_83xx) || \
+ defined(CONFIG_MPC10X_BRIDGE) || defined(CONFIG_8260) || \
+ defined(CONFIG_PPC_MPC52xx))
+
+#if USES_PPC_SYS
#include <asm/ppc_sys.h>
#endif
@@ -241,7 +245,7 @@ int show_cpuinfo(struct seq_file *m, voi
seq_printf(m, "bogomips\t: %lu.%02lu\n",
lpj / (500000/HZ), (lpj / (5000/HZ)) % 100);
-#if defined(CONFIG_85xx) || defined(CONFIG_83xx) || defined(CONFIG_MPC10X_BRIDGE)
+#if USES_PPC_SYS
if (cur_ppc_sys_spec->ppc_sys_name)
seq_printf(m, "chipset\t\t: %s\n",
cur_ppc_sys_spec->ppc_sys_name);
diff --git a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile
+++ b/arch/ppc/syslib/Makefile
@@ -82,7 +82,8 @@ obj-$(CONFIG_SANDPOINT) += i8259.o pci_
obj-$(CONFIG_SBC82xx) += todc_time.o
obj-$(CONFIG_SPRUCE) += cpc700_pic.o indirect_pci.o pci_auto.o \
todc_time.o
-obj-$(CONFIG_8260) += m8260_setup.o
+obj-$(CONFIG_8260) += m8260_setup.o pq2_devices.o pq2_sys.o \
+ ppc_sys.o
obj-$(CONFIG_PCI_8260) += m82xx_pci.o indirect_pci.o pci_auto.o
obj-$(CONFIG_8260_PCI9) += m8260_pci_erratum9.o
obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
diff --git a/arch/ppc/syslib/pq2_devices.c b/arch/ppc/syslib/pq2_devices.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/pq2_devices.c
@@ -0,0 +1,389 @@
+/*
+ * arch/ppc/syslib/pq2_devices.c
+ *
+ * PQ2 Device descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/ioport.h>
+#include <asm/cpm2.h>
+#include <asm/irq.h>
+#include <asm/ppc_sys.h>
+
+struct platform_device ppc_sys_platform_devices[] = {
+ [MPC82xx_CPM_FCC1] = {
+ .name = "fsl-cpm-fcc",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "fcc_regs",
+ .start = 0x11300,
+ .end = 0x1131f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "fcc_pram",
+ .start = 0x8400,
+ .end = 0x84ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_FCC1,
+ .end = SIU_INT_FCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_FCC2] = {
+ .name = "fsl-cpm-fcc",
+ .id = 2,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "fcc_regs",
+ .start = 0x11320,
+ .end = 0x1133f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "fcc_pram",
+ .start = 0x8500,
+ .end = 0x85ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_FCC2,
+ .end = SIU_INT_FCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_FCC3] = {
+ .name = "fsl-cpm-fcc",
+ .id = 3,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "fcc_regs",
+ .start = 0x11340,
+ .end = 0x1135f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "fcc_pram",
+ .start = 0x8600,
+ .end = 0x86ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_FCC3,
+ .end = SIU_INT_FCC3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_I2C] = {
+ .name = "fsl-cpm-i2c",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "i2c_mem",
+ .start = 0x11860,
+ .end = 0x118BF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "i2c_pram",
+ .start = 0x8afc,
+ .end = 0x8afd,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_I2C,
+ .end = SIU_INT_I2C,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SCC1] = {
+ .name = "fsl-cpm-scc",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "scc_mem",
+ .start = 0x11A00,
+ .end = 0x11A1F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "scc_pram",
+ .start = 0x8000,
+ .end = 0x80ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC1,
+ .end = SIU_INT_SCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SCC2] = {
+ .name = "fsl-cpm-scc",
+ .id = 2,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "scc_mem",
+ .start = 0x11A20,
+ .end = 0x11A3F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "scc_pram",
+ .start = 0x8100,
+ .end = 0x81ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC2,
+ .end = SIU_INT_SCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SCC3] = {
+ .name = "fsl-cpm-scc",
+ .id = 3,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "scc_mem",
+ .start = 0x11A40,
+ .end = 0x11A5F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "scc_pram",
+ .start = 0x8200,
+ .end = 0x82ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC3,
+ .end = SIU_INT_SCC3,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SCC4] = {
+ .name = "fsl-cpm-scc",
+ .id = 4,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "scc_mem",
+ .start = 0x11A60,
+ .end = 0x11A7F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "scc_pram",
+ .start = 0x8300,
+ .end = 0x83ff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SCC4,
+ .end = SIU_INT_SCC4,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SPI] = {
+ .name = "fsl-cpm-spi",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "spi_mem",
+ .start = 0x11AA0,
+ .end = 0x11AFF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "spi_pram",
+ .start = 0x89fc,
+ .end = 0x89fd,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SPI,
+ .end = SIU_INT_SPI,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_MCC1] = {
+ .name = "fsl-cpm-mcc",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "mcc_mem",
+ .start = 0x11B30,
+ .end = 0x11B3F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "mcc_pram",
+ .start = 0x8700,
+ .end = 0x877f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_MCC1,
+ .end = SIU_INT_MCC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_MCC2] = {
+ .name = "fsl-cpm-mcc",
+ .id = 2,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "mcc_mem",
+ .start = 0x11B50,
+ .end = 0x11B5F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "mcc_pram",
+ .start = 0x8800,
+ .end = 0x887f,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_MCC2,
+ .end = SIU_INT_MCC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SMC1] = {
+ .name = "fsl-cpm-smc",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "smc_mem",
+ .start = 0x11A80,
+ .end = 0x11A8F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "smc_pram",
+ .start = 0x87fc,
+ .end = 0x87fd,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SMC1,
+ .end = SIU_INT_SMC1,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_SMC2] = {
+ .name = "fsl-cpm-smc",
+ .id = 2,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "smc_mem",
+ .start = 0x11A90,
+ .end = 0x11A9F,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "smc_pram",
+ .start = 0x88fc,
+ .end = 0x88fd,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_SMC2,
+ .end = SIU_INT_SMC2,
+ .flags = IORESOURCE_IRQ,
+ },
+ },
+ },
+ [MPC82xx_CPM_USB] = {
+ .name = "fsl-cpm-usb",
+ .id = 1,
+ .num_resources = 3,
+ .resource = (struct resource[]) {
+ {
+ .name = "usb_mem",
+ .start = 0x11b60,
+ .end = 0x11b78,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "usb_pram",
+ .start = 0x8b00,
+ .end = 0x8bff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = SIU_INT_USB,
+ .end = SIU_INT_USB,
+ .flags = IORESOURCE_IRQ,
+ },
+
+ },
+ },
+ [MPC82xx_SEC1] = {
+ .name = "fsl-sec",
+ .id = 1,
+ .num_resources = 1,
+ .resource = (struct resource[]) {
+ {
+ .name = "sec_mem",
+ .start = 0x40000,
+ .end = 0x52fff,
+ .flags = IORESOURCE_MEM,
+ },
+ },
+ },
+};
+
+static int __init mach_mpc82xx_fixup(struct platform_device *pdev)
+{
+ ppc_sys_fixup_mem_resource(pdev, CPM_MAP_ADDR);
+ return 0;
+}
+
+static int __init mach_mpc82xx_init(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mach_mpc82xx_init:enter", 0);
+ ppc_sys_device_fixup = mach_mpc82xx_fixup;
+ return 0;
+}
+
+postcore_initcall(mach_mpc82xx_init);
diff --git a/arch/ppc/syslib/pq2_sys.c b/arch/ppc/syslib/pq2_sys.c
new file mode 100644
--- /dev/null
+++ b/arch/ppc/syslib/pq2_sys.c
@@ -0,0 +1,200 @@
+/*
+ * arch/ppc/syslib/pq2_devices.c
+ *
+ * PQ2 System descriptions
+ *
+ * Maintainer: Kumar Gala <kumar.gala@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+
+#include <asm/ppc_sys.h>
+
+struct ppc_sys_spec *cur_ppc_sys_spec;
+struct ppc_sys_spec ppc_sys_specs[] = {
+ /* below is a list of the 8260 family of processors */
+ {
+ .ppc_sys_name = "8250",
+ .mask = 0x0000ff00,
+ .value = 0x00000000,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ }
+ },
+ {
+ .ppc_sys_name = "8255",
+ .mask = 0x0000ff00,
+ .value = 0x00000000,
+ .num_devices = 11,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SCC4,
+ MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2,
+ MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ }
+ },
+ {
+ .ppc_sys_name = "8260",
+ .mask = 0x0000ff00,
+ .value = 0x00000000,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ }
+ },
+ {
+ .ppc_sys_name = "8264",
+ .mask = 0x0000ff00,
+ .value = 0x00000000,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ }
+ },
+ {
+ .ppc_sys_name = "8265",
+ .mask = 0x0000ff00,
+ .value = 0x00000000,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ }
+ },
+ {
+ .ppc_sys_name = "8266",
+ .mask = 0x0000ff00,
+ .value = 0x00000000,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ }
+ },
+ /* below is a list of the 8272 family of processors */
+ {
+ .ppc_sys_name = "8247",
+ .mask = 0x0000ff00,
+ .value = 0x00000d00,
+ .num_devices = 10,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ MPC82xx_CPM_USB,
+ },
+ },
+ {
+ .ppc_sys_name = "8248",
+ .mask = 0x0000ff00,
+ .value = 0x00000c00,
+ .num_devices = 11,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ MPC82xx_CPM_USB, MPC82xx_SEC1,
+ },
+ },
+ {
+ .ppc_sys_name = "8271",
+ .mask = 0x0000ff00,
+ .value = 0x00000d00,
+ .num_devices = 10,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ MPC82xx_CPM_USB,
+ },
+ },
+ {
+ .ppc_sys_name = "8272",
+ .mask = 0x0000ff00,
+ .value = 0x00000c00,
+ .num_devices = 11,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_SCC1,
+ MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ MPC82xx_CPM_USB, MPC82xx_SEC1,
+ },
+ },
+ /* below is a list of the 8280 family of processors */
+ {
+ .ppc_sys_name = "8270",
+ .mask = 0x0000ff00,
+ .value = 0x00000a00,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ },
+ },
+ {
+ .ppc_sys_name = "8275",
+ .mask = 0x0000ff00,
+ .value = 0x00000a00,
+ .num_devices = 12,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI, MPC82xx_CPM_I2C,
+ },
+ },
+ {
+ .ppc_sys_name = "8280",
+ .mask = 0x0000ff00,
+ .value = 0x00000a00,
+ .num_devices = 13,
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC82xx_CPM_FCC1, MPC82xx_CPM_FCC2, MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_SCC1, MPC82xx_CPM_SCC2, MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4, MPC82xx_CPM_MCC1, MPC82xx_CPM_MCC2,
+ MPC82xx_CPM_SMC1, MPC82xx_CPM_SMC2, MPC82xx_CPM_SPI,
+ MPC82xx_CPM_I2C,
+ },
+ },
+ {
+ /* default match */
+ .ppc_sys_name = "",
+ .mask = 0x00000000,
+ .value = 0x00000000,
+ },
+};
diff --git a/include/asm-ppc/irq.h b/include/asm-ppc/irq.h
--- a/include/asm-ppc/irq.h
+++ b/include/asm-ppc/irq.h
@@ -337,6 +337,7 @@ static __inline__ int irq_canonicalize(i
#define SIU_INT_IDMA3 ((uint)0x08 + CPM_IRQ_OFFSET)
#define SIU_INT_IDMA4 ((uint)0x09 + CPM_IRQ_OFFSET)
#define SIU_INT_SDMA ((uint)0x0a + CPM_IRQ_OFFSET)
+#define SIU_INT_USB ((uint)0x0b + CPM_IRQ_OFFSET)
#define SIU_INT_TIMER1 ((uint)0x0c + CPM_IRQ_OFFSET)
#define SIU_INT_TIMER2 ((uint)0x0d + CPM_IRQ_OFFSET)
#define SIU_INT_TIMER3 ((uint)0x0e + CPM_IRQ_OFFSET)
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -67,6 +67,24 @@
#define IO_VIRT_ADDR IO_PHYS_ADDR
#endif
+enum ppc_sys_devices {
+ MPC82xx_CPM_FCC1,
+ MPC82xx_CPM_FCC2,
+ MPC82xx_CPM_FCC3,
+ MPC82xx_CPM_I2C,
+ MPC82xx_CPM_SCC1,
+ MPC82xx_CPM_SCC2,
+ MPC82xx_CPM_SCC3,
+ MPC82xx_CPM_SCC4,
+ MPC82xx_CPM_SPI,
+ MPC82xx_CPM_MCC1,
+ MPC82xx_CPM_MCC2,
+ MPC82xx_CPM_SMC1,
+ MPC82xx_CPM_SMC2,
+ MPC82xx_CPM_USB,
+ MPC82xx_SEC1,
+};
+
#ifndef __ASSEMBLY__
/* The "residual" data board information structure the boot loader
* hands to us.
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -21,7 +21,9 @@
#include <linux/device.h>
#include <linux/types.h>
-#if defined(CONFIG_83xx)
+#if defined(CONFIG_8260)
+#include <asm/mpc8260.h>
+#elif defined(CONFIG_83xx)
#include <asm/mpc83xx.h>
#elif defined(CONFIG_85xx)
#include <asm/mpc85xx.h>
^ permalink raw reply
* copy_from_user problem
From: V MURAHARI @ 2005-08-11 2:52 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/html, Size: 3645 bytes --]
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Olof Johansson @ 2005-08-11 1:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <20050811100911.7b3ac089.sfr@canb.auug.org.au>
On Thu, Aug 11, 2005 at 10:09:11AM +1000, Stephen Rothwell wrote:
> On Wed, 10 Aug 2005 11:45:10 -0500 Becky Bruce
> <becky.bruce@freescale.com> wrote:
> >
> > platforms/
> > - platform-specific code laid out in the following
> > directories: pSeries/
> > iSeries/
>
> Please, lets get rid of the StudLy CaPs :-)
Actually, might be a good time to start calling pSeries something else
too, since it's no longer just pSeries that uses the platform.
papr? rpa?
-Olof
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Stephen Rothwell @ 2005-08-11 0:09 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <c237b7e878e0c32f421209fa37b7a156@freescale.com>
On Wed, 10 Aug 2005 11:45:10 -0500 Becky Bruce
<becky.bruce@freescale.com> wrote:
>
> platforms/
> - platform-specific code laid out in the following
> directories: pSeries/
> iSeries/
Please, lets get rid of the StudLy CaPs :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Action Required -- Credit/Debit Card Expiration Reminder
From: aw-confirm @ 2005-08-10 23:35 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 3395 bytes --]
^ permalink raw reply
* Action Required -- Credit/Debit Card Expiration Reminder
From: aw-confirm @ 2005-08-10 23:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 3395 bytes --]
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Dale Farnsworth @ 2005-08-10 23:20 UTC (permalink / raw)
To: Thomas S., linuxppc-embedded list
In-Reply-To: <42FA5932.4070002@schnuerer-online.de>
On Wed, Aug 10, 2005 at 07:44:50PM +0000, 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
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: John W. Linville @ 2005-08-10 21:35 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Becky Bruce, linuxppc64-dev
In-Reply-To: <22fac6c20e1ee142606e4295722c2d1d@embeddededge.com>
On Wed, Aug 10, 2005 at 01:01:34PM -0400, Dan Malek wrote:
> inside of them. Regardless of the build or management tools we use, I
> still find it
> nice to keep a concise file name that is still descriptive, and take
> advantage of
> the directory structure names to assist with this.
I'll second that, fwiw...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* RE: pci_enable_device fails on MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-08-10 20:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6013 bytes --]
HI Kumar,
I have attached the /proc/ioports and /proc/iomem for 8541E.
Also the CONFIG_ 85XX_PCI2 is set to yes.
Freescale does not support 2.6.13 so I am not able to update to that
version yet.
Thanks,
Bizhan
-----Original Message-----
From: Kumar Gala [mailto:kumar.gala@freescale.com]
Sent: Wednesday, August 10, 2005 12:11 PM
To: Bizhan Gholikhamseh (bgholikh)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 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@freescale.com]
> Sent: Wednesday, August 10, 2005 9:06 AM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@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@freescale.com]
>> Sent: Tuesday, August 09, 2005 4:11 PM
>> To: Bizhan Gholikhamseh (bgholikh)
>> Cc: linuxppc-embedded@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 0000: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@freescale.com]
>>> Sent: Monday, August 08, 2005 1:34 PM
>>> To: Bizhan Gholikhamseh (bgholikh)
>>> Cc: linuxppc-embedded@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 0000: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 FUN VendorID DeviceID Device Class Sub-Class
>>>> -------------------------------------------------------------------
>>>> -
>>>>
>
>
>>>> -
>>>>
>>>>
>>
>>
>>
>>>> -
>>>> --
>>>> --------------------
>>>> 03.01.00 0x104c 0xa106 .........
>>>>
>>>> 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>
>
[-- Attachment #2: proc_ioports_iomem.txt --]
[-- Type: text/plain, Size: 1456 bytes --]
# cat /proc/ioports
00000000-00ffffff : PCI1 host bridge
00000000-0000ffff : PCI Bus #02
00000000-0000ffff : PCI Bus #01
00000020-00000021 : 8259 (master)
00000060-0000006f : i8042
000000a0-000000a1 : 8259 (slave)
000004d0-000004d1 : 8259 edge control
0000cc00-0000cc0f : 0000:01:02.1
0000fc00-0000fcff : 0000:01:02.6
0000fdf8-0000fdfb : 0000:01:02.5
0000fdfc-0000fdff : 0000:01:02.5
0000fe00-0000feff : 0000:01:02.5
0000ffc0-0000ffdf : 0000:01:02.3
0000ffe0-0000ffff : 0000:01:02.2
01000000-01ffffff : PCI2 host bridge
# cat /proc/iomem
80000000-9fffffff : PCI1 host bridge
9ef00000-9effffff : PCI Bus #02
9f000000-9fcfffff : PCI Bus #02
9f000000-9f7fffff : 0000:02:01.0
9f800000-9fbfffff : 0000:02:01.0
9fd00000-9fdfffff : PCI Bus #01
9fe00000-9fefffff : PCI Bus #01
9ffff000-9fffffff : 0000:00:11.0
a0000000-bfffffff : PCI2 host bridge
e0003000-e0003fff : fsl-i2c1
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0021100-e002117f : fsl-dma0
e0021180-e00211ff : fsl-dma1
e0021200-e002127f : fsl-dma2
e0021280-e00212ff : fsl-dma3
e0024000-e0024fff : fsl-gianfar1
e0025000-e0025fff : fsl-gianfar2
e0030000-e003ffff : fsl-sec21
e0091300-e009131f : fsl-cpm-fcc1
e0091320-e009133f : fsl-cpm-fcc2
e0091380-e009139f : fsl-cpm-fcc1
e00913a0-e00913cf : fsl-cpm-fcc2
e0091860-e00918bf : fsl-cpm-i2c1
e0091aa0-e0091aff : fsl-cpm-spi1
e00e1000-e00e1fff : fsl-perfmon1
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Thomas S. @ 2005-08-10 19:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: thomas.schnuerer, linuxppc-embedded list
In-Reply-To: <75E0EACF-3C16-45AE-A0D2-CE999AF9AC7B@freescale.com>
Kumar,
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).
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.h 1969-12-31 17:00:00.000000000 -0700
>>>> +++ b/include/asm-ppc/usb.h 2005-08-05 06:13:58.000000000 -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@schnuerer-online.de>
>>>>>> Date: August 8, 2005 4:48:03 PM CDT
>>>>>> To: <linux-kernel@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@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@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Kumar Gala @ 2005-08-10 19:53 UTC (permalink / raw)
To: Thomas S.; +Cc: thomas.schnuerer, linuxppc-embedded list
In-Reply-To: <42FA5932.4070002@schnuerer-online.de>
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.h 1969-12-31 17:00:00.000000000 -0700
>>>>> +++ b/include/asm-ppc/usb.h 2005-08-05 06:13:58.000000000 -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@schnuerer-online.de>
>>>>>>> Date: August 8, 2005 4:48:03 PM CDT
>>>>>>> To: <linux-kernel@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@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@ozlabs.org
>>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
^ permalink raw reply
* Re: PowerBook5,4 sleep w/2.6.12
From: Owen Stampflee @ 2005-08-10 19:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1123689464.3664.10.camel@beast.terraplex.com>
Turns out that somehow CPUFREQ was forgotten in the config,enabling it
fixed the problem.
Thanks for the input guys.
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Kumar Gala @ 2005-08-10 19:16 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <42FA4108.9090808@ru.mvista.com>
+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@ru.mvista.com>
>
> --
> Sincerely,
> Vitaly
>
> <ppc_sys_add.patch>
> <ATT87954.txt>
>
^ 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