* 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
* Re: pci_enable_device fails on MPC8541
From: Kumar Gala @ 2005-08-10 19:11 UTC (permalink / raw)
To: Bizhan Gholikhamseh \((bgholikh\)); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641584950A@xmb-sjc-212.amer.cisco.com>
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>
>
^ permalink raw reply
* RE: pci_enable_device fails on MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-08-10 18:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4111 bytes --]
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>
>
[-- Attachment #2: pci_boot_8540.txt --]
[-- Type: text/plain, Size: 482 bytes --]
PCI: Probing PCI hardware
PCI: bridge rsrc 0..ffffff (100), parent c0203818
PCI: bridge rsrc 80000000..9fffffff (200), parent c02037fc
PCI: bridge rsrc fff000..ffffff (101), parent c0293038
PCI: bridge rsrc 9f000000..9fffffff (200), parent c0293054
PCI: bridge rsrc 9ef00000..9effffff (1201), parent c0293054
PCI:0000:01:01.0: Resource 0: 9fc00000-9fffffff (f=1208)
PCI:0000:01:01.0: Resource 1: 9f000000-9f7fffff (f=200)
PCI:0000:01:01.0: Resource 2: 00fffff0-00ffffff (f=101)
[-- Attachment #3: proc_pci_8540.txt --]
[-- Type: text/plain, Size: 524 bytes --]
# cat /proc/pci
PCI devices found:
Bus 0, device 21, function 0:
PCI bridge: Texas Instruments PCI2050 PCI-to-PCI Bridge (rev 2).
IRQ 98.
Master Capable. Latency=128.
Bus 1, device 1, function 0:
Non-VGA unclassified device: Texas Instruments TMS320C6205 Fixed Point DSP (rev 1). IRQ 99.
Master Capable. Latency=128.
Prefetchable 32 bit memory at 0x9fc00000 [0x9fffffff].
Non-prefetchable 32 bit memory at 0x9f000000 [0x9f7fffff].
I/O at 0xfffff0 [0xffffff].
^ permalink raw reply
* [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-10 18:01 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <42FA3D7B.8040200@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 112 bytes --]
Finally correct indentation style.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: ppc_sys_add.patch --]
[-- Type: text/x-patch, Size: 2173 bytes --]
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -6,6 +6,7 @@
* Maintainer: Kumar Gala <kumar.gala@freescale.com>
*
* Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005 MontaVista, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
*
* 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
@@ -33,10 +34,46 @@ void __init identify_ppc_sys_by_id(u32 i
return;
}
-void __init identify_ppc_sys_by_name(char *name)
+static int __init count_sys_specs(void)
{
- /* TODO */
- return;
+ int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name, ""))
+ i++;
+ return i;
+}
+
+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()];
+
+ 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;
+}
+
+void __init identify_ppc_sys_by_name_and_id(char *name, u32 id)
+{
+ int i = find_chip_by_name_and_id(name, id);
+ BUG_ON(i < 0);
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
}
/* Update all memory resources by paddr, call before platform_device_register */
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
@@ -51,7 +51,7 @@ extern struct ppc_sys_spec *cur_ppc_sys_
/* determine which specific SOC we are */
extern void identify_ppc_sys_by_id(u32 id) __init;
-extern void identify_ppc_sys_by_name(char *name) __init;
+extern void identify_ppc_sys_by_name_and_id(char *name, u32 id) __init;
/* describes all devices that may exist in a given family of processors */
extern struct platform_device ppc_sys_platform_devices[];
^ permalink raw reply
* [PATCH] identify_ppc_sys_by_name_and_id function implementation (braces fixed)
From: Vitaly Bordug @ 2005-08-10 17:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <42FA3636.7010804@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 133 bytes --]
The same as above but with correct kernel bracing style.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: ppc_sys_add.patch --]
[-- Type: text/x-patch, Size: 2174 bytes --]
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -6,6 +6,7 @@
* Maintainer: Kumar Gala <kumar.gala@freescale.com>
*
* Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005 MontaVista, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
*
* 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
@@ -33,10 +34,45 @@ void __init identify_ppc_sys_by_id(u32 i
return;
}
-void __init identify_ppc_sys_by_name(char *name)
+static int __init count_sys_specs(void)
{
- /* TODO */
- return;
+ int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name,""))
+ i++;
+ return i;
+}
+
+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()];
+
+ 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;
+}
+
+void __init identify_ppc_sys_by_name_and_id(char* name, u32 id)
+{
+ int i = find_chip_by_name_and_id(name,id);
+ BUG_ON(i < 0);
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
}
/* Update all memory resources by paddr, call before platform_device_register */
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
@@ -51,7 +51,7 @@ extern struct ppc_sys_spec *cur_ppc_sys_
/* determine which specific SOC we are */
extern void identify_ppc_sys_by_id(u32 id) __init;
-extern void identify_ppc_sys_by_name(char *name) __init;
+extern void identify_ppc_sys_by_name_and_id(char *name, u32 id) __init;
/* describes all devices that may exist in a given family of processors */
extern struct platform_device ppc_sys_platform_devices[];
^ permalink raw reply
* [PATCH] Use todc on Mot PReP platforms
From: Matt Porter @ 2005-08-10 16:37 UTC (permalink / raw)
To: linuxppc-dev
This restores behavior from 2.4 where PReP platforms identified
as Motorola would calibrate the decrementer using the RTC. On
real Motorola PReP hardware this isn't needed. However, in order
to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
PReP system) it is necessary to allow it to calibrate the decrementer
using an emulated RTC. If the decrementer rate is read from
residual data then timing is screwed since a qemu PReP system typically
runs much faster than the original hardware.
If anybody has objections to this as the default, let me know. It
still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
affect the IBM PReP paths. My goal with this is to be able to run
a stock 2.6 defconfig PReP build on qemu.
-Matt
diff --git a/arch/ppc/platforms/prep_setup.c b/arch/ppc/platforms/prep_setup.c
--- a/arch/ppc/platforms/prep_setup.c
+++ b/arch/ppc/platforms/prep_setup.c
@@ -940,8 +940,7 @@ prep_calibrate_decr(void)
tb_to_us = mulhwu_scale_factor(freq/divisor, 1000000);
tb_ticks_per_jiffy = freq / HZ / divisor;
}
- }
- else
+ } else
todc_calibrate_decr();
}
@@ -1155,16 +1154,17 @@ prep_init(unsigned long r3, unsigned lon
ppc_md.time_init = todc_time_init;
if (_prep_type == _PREP_IBM) {
+ ppc_md.calibrate_decr = prep_calibrate_decr;
ppc_md.rtc_read_val = todc_mc146818_read_val;
ppc_md.rtc_write_val = todc_mc146818_write_val;
TODC_INIT(TODC_TYPE_MC146818, RTC_PORT(0), NULL, RTC_PORT(1),
8);
} else {
+ ppc_md.calibrate_decr = todc_calibrate_decr;
TODC_INIT(TODC_TYPE_MK48T59, PREP_NVRAM_AS0, PREP_NVRAM_AS1,
PREP_NVRAM_DATA, 8);
}
- ppc_md.calibrate_decr = prep_calibrate_decr;
ppc_md.set_rtc_time = todc_set_rtc_time;
ppc_md.get_rtc_time = todc_get_rtc_time;
^ permalink raw reply
* [RFC][PATCH] identify_ppc_sys_by_name_and_id function implementation
From: Vitaly Bordug @ 2005-08-10 17:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
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@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: ppc_sys_add.patch --]
[-- Type: text/x-patch, Size: 2183 bytes --]
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -6,6 +6,7 @@
* Maintainer: Kumar Gala <kumar.gala@freescale.com>
*
* Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005 MontaVista, Inc. by Vitaly Bordug <vbordug@ru.mvista.com>
*
* 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
@@ -33,10 +34,48 @@ void __init identify_ppc_sys_by_id(u32 i
return;
}
-void __init identify_ppc_sys_by_name(char *name)
+static int __init count_sys_specs(void)
{
- /* TODO */
- return;
+ int i = 0;
+ while (strcmp(ppc_sys_specs[i].ppc_sys_name,""))
+ i++;
+ return i;
+}
+
+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()];
+
+ 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;
+}
+
+void __init identify_ppc_sys_by_name_and_id(char* name, u32 id)
+{
+ int i = find_chip_by_name_and_id(name,id);
+ BUG_ON(i < 0);
+ cur_ppc_sys_spec = &ppc_sys_specs[i];
}
/* Update all memory resources by paddr, call before platform_device_register */
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
@@ -51,7 +51,7 @@ extern struct ppc_sys_spec *cur_ppc_sys_
/* determine which specific SOC we are */
extern void identify_ppc_sys_by_id(u32 id) __init;
-extern void identify_ppc_sys_by_name(char *name) __init;
+extern void identify_ppc_sys_by_name_and_id(char *name, u32 id) __init;
/* describes all devices that may exist in a given family of processors */
extern struct platform_device ppc_sys_platform_devices[];
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Dan Malek @ 2005-08-10 17:01 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <c237b7e878e0c32f421209fa37b7a156@freescale.com>
On Aug 10, 2005, at 12:45 PM, Becky Bruce wrote:
> .... Listed below are the proposed directories, along with a
> description of the logical contents, as well as a description of which
> existing files will be moved into these directories.
I think this is fine, but I'd like to make a suggestion about the file
names themselves.
Since we have platform directories for a specific processor type or
core, can we
change the file names a little? For example, if I'm in the
platforms/82xx directory,
I don't need to prepend every file with mpc82xx_ or ppc82xx- or
whatever. We
know that's what it is, let's try to use the file names to be more
descriptive of what's
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.
Thanks.
-- Dan
^ 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