* 8xx i2c refers to unspecified chip errata @ 2002-10-09 20:14 Barker Michael-r43496 2002-10-10 10:35 ` Joakim Tjernlund 0 siblings, 1 reply; 30+ messages in thread From: Barker Michael-r43496 @ 2002-10-09 20:14 UTC (permalink / raw) To: linuxppc-embedded Hi - I've been looking at the i2c driver for MPC8260. It's the first linux driver I have studied. I have a couple of questions. What experimental results or theory are behind the timeout values chosen when waiting for an interrupt from a write transaction? Also: in the drivers/i2c/i2c-algo-cpm.c or i2c-algo-8xx.c file, I see the following a few times. What two chip errata are the comments referring to? A specific errata number would be enlightening. ---------snip /* Chip errata, clear enable. */ i2c->i2c_i2mod = 0; ---------snip /* Chip bug, set enable here */ save_flags(flags); cli(); i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ i2c->i2c_i2cer = 0xff; i2c->i2c_i2mod = 1; /* Enable */ i2c->i2c_i2com = 0x81; /* Start master */ ----------snip Thanks for your attention - -- Michael D. Barker, Motorola SPS Canada This email along with any attachments is classified as: [x] General business information ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-09 20:14 8xx i2c refers to unspecified chip errata Barker Michael-r43496 @ 2002-10-10 10:35 ` Joakim Tjernlund 2002-10-10 16:18 ` Dan Malek 0 siblings, 1 reply; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-10 10:35 UTC (permalink / raw) To: Barker Michael-r43496, linuxppc-embedded > > Also: in the drivers/i2c/i2c-algo-cpm.c or i2c-algo-8xx.c file, I see the following a few times. What two chip errata > are the comments referring to? A specific errata number would be enlightening. I think these refer to older revision of mpc8xx CPU. In the mpc860 only the latest CPU rev(D4) has all relevant I2C bugs fixed. The fix below does not work well in my MPC860(rev D4). I think it's because I2C is disabled before it had a chence to generate a proper STOP condition and that hangs my DS1337 RTC clock badly(need to reboot to fix it). The driver(i2c-algo-8xx.c) that comes with the kernel has other severe bugs(memory corruption etc.) as well. > > ---------snip > /* Chip errata, clear enable. > */ > i2c->i2c_i2mod = 0; > > ---------snip > /* Chip bug, set enable here */ > save_flags(flags); cli(); > i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ > i2c->i2c_i2cer = 0xff; > i2c->i2c_i2mod = 1; /* Enable */ > i2c->i2c_i2com = 0x81; /* Start master */ > ----------snip > > Thanks for your attention - > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-10 10:35 ` Joakim Tjernlund @ 2002-10-10 16:18 ` Dan Malek 2002-10-10 16:35 ` Dr. Craig Hollabaugh 2002-10-11 7:28 ` Joakim Tjernlund 0 siblings, 2 replies; 30+ messages in thread From: Dan Malek @ 2002-10-10 16:18 UTC (permalink / raw) To: joakim.tjernlund; +Cc: Barker Michael-r43496, linuxppc-embedded Joakim Tjernlund wrote: > .... The driver(i2c-algo-8xx.c) that > comes with the kernel has other severe bugs(memory corruption etc.) as well. Just toggle the bits in software. I never saw an application where the I2C controller provided a performance advantage. It's lots of software to execute, along with all of the interrupt handling and stuff, so you just spend lots of overhead not making any other progress. Make sure you carefully analyze the entire system performance advantages. Using the controller assitance just because it is there isn't always the proper solution. Same is true for the SPI. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-10 16:18 ` Dan Malek @ 2002-10-10 16:35 ` Dr. Craig Hollabaugh 2002-10-11 7:28 ` Joakim Tjernlund 1 sibling, 0 replies; 30+ messages in thread From: Dr. Craig Hollabaugh @ 2002-10-10 16:35 UTC (permalink / raw) To: Dan Malek; +Cc: joakim.tjernlund, Barker Michael-r43496, linuxppc-embedded > Joakim Tjernlund wrote: > > > .... The driver(i2c-algo-8xx.c) that > > comes with the kernel has other severe bugs(memory corruption etc.) as well. > Dan Wrote > Just toggle the bits in software. I never saw an application where the I2C > controller provided a performance advantage. It's lots of software to execute, > along with all of the interrupt handling and stuff, so you just spend lots of > overhead not making any other progress. > > Make sure you carefully analyze the entire system performance advantages. > Using the controller assitance just because it is there isn't always the > proper solution. Same is true for the SPI. Here's a link to my book's I2C bit banging code for 8xx http://www.embeddedlinuxinterfacing.com/chapters/10/SAA1064_rpxcllf.c You can pull the I2C routines from this code. Let me know if you have any questions. Craig ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-10 16:18 ` Dan Malek 2002-10-10 16:35 ` Dr. Craig Hollabaugh @ 2002-10-11 7:28 ` Joakim Tjernlund 2002-10-11 7:50 ` bart 1 sibling, 1 reply; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-11 7:28 UTC (permalink / raw) To: Dan Malek; +Cc: Barker Michael-r43496, linuxppc-embedded Hi Dan > Joakim Tjernlund wrote: > > > .... The driver(i2c-algo-8xx.c) that > > comes with the kernel has other severe bugs(memory corruption etc.) as well. > > Just toggle the bits in software. I never saw an application where the I2C > controller provided a performance advantage. It's lots of software to execute, > along with all of the interrupt handling and stuff, so you just spend lots of > overhead not making any other progress. I2C speed is not very important to me, but freeing up the CPU to do other things is. If there are just a few bytes data to read/write it probably does not matter, but if you read/write I2C memories(>128 bytes) it will matter and the I2C controller will make a difference. One could also adjust the i2c-algo-8xx.c to busy wait for small reads/writes instead of using interrupts if the interrupt handling overhead is significant. Anyway I have fixed the bugs in i2c-algo-8xx.c driver and it's working great for me so I think I will stick with it for the time being. Thanks Jocke > > Make sure you carefully analyze the entire system performance advantages. > Using the controller assitance just because it is there isn't always the > proper solution. Same is true for the SPI. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-11 7:28 ` Joakim Tjernlund @ 2002-10-11 7:50 ` bart 2002-10-11 9:12 ` Joakim Tjernlund 0 siblings, 1 reply; 30+ messages in thread From: bart @ 2002-10-11 7:50 UTC (permalink / raw) To: joakim.tjernlund; +Cc: linuxppc-embedded Hi Joakim, > Anyway I have fixed the bugs in i2c-algo-8xx.c driver and it's working great for me > so I think I will stick with it for the time being. > Could you please post the fixes on the list? I also might want to use them. Thanks, Bart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-11 7:50 ` bart @ 2002-10-11 9:12 ` Joakim Tjernlund 2002-10-11 9:56 ` bart ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-11 9:12 UTC (permalink / raw) To: bart; +Cc: linuxppc-embedded [-- Attachment #1: Type: text/plain, Size: 335 bytes --] OK, here it is. Perhaps someone can add it to the ppctree? Jocke > > > Hi Joakim, > > > Anyway I have fixed the bugs in i2c-algo-8xx.c driver and it's working great for me > > so I think I will stick with it for the time being. > > > Could you please post the fixes on the list? I also might want to use them. > > Thanks, > Bart > [-- Attachment #2: i2c-algo-8xx.c --] [-- Type: application/octet-stream, Size: 16179 bytes --] /* * i2c-algo-8xx.c i2x driver algorithms for MPC8XX CPM * Copyright (c) 1999 Dan Malek (dmalek@jlc.net). * * moved into proper i2c interface; separated out platform specific * parts into ic-rpx.c * Brad Parker (brad@heeltoe.com) */ /* $Id: i2c-algo-8xx.c,v 1.3 2001/11/21 17:20:22 jocke Exp $ */ #include <linux/kernel.h> #include <linux/module.h> #include <linux/delay.h> #include <linux/slab.h> #include <linux/version.h> #include <linux/init.h> #include <asm/uaccess.h> #include <linux/ioport.h> #include <linux/errno.h> #include <linux/sched.h> #include <asm/mpc8xx.h> #include <asm/commproc.h> #include <linux/i2c.h> #include <linux/i2c-algo-8xx.h> #define CPM_MAX_READ 513 /* #define I2C_CHIP_ERRATA */ /* Try uncomment this if you have an older CPU(earlier than rev D4) */ static wait_queue_head_t iic_wait; static ushort r_tbase, r_rbase; static u8 irq_flags; int cpm_scan = 0; int cpm_debug = 0; static void cpm_iic_interrupt(void *dev_id, struct pt_regs *regs) { volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id; if (cpm_debug > 1) printk("cpm_iic_interrupt(dev_id=%p)\n", dev_id); #if 0 /* Chip errata, clear enable. This is not needed on rev D4 CPUs */ /* This should probably be removed and replaced by I2C_CHIP_ERRATA stuff */ /* Someone with a buggy CPU needs to confirm that */ i2c->i2c_i2mod &= ~1; #endif /* Clear interrupt. */ irq_flags = i2c->i2c_i2cer; i2c->i2c_i2cer = 0xff; /* Get 'me going again. */ wake_up_interruptible(&iic_wait); } static void cpm_iic_init(struct i2c_algo_8xx_data *cpm_adap) { volatile iic_t *iip = cpm_adap->iip; volatile i2c8xx_t *i2c = cpm_adap->i2c; unsigned char brg; bd_t *bd = (bd_t *)__res; if (cpm_debug) printk("cpm_iic_init()\n"); /* Initialize the parameter ram. * We need to make sure many things are initialized to zero, * especially in the case of a microcode patch. */ iip->iic_rstate = 0; iip->iic_rdp = 0; 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; /* Set up the IIC parameters in the parameter ram. */ iip->iic_tbase = r_tbase = cpm_adap->dp_addr; iip->iic_rbase = r_rbase = cpm_adap->dp_addr + sizeof(cbd_t)*2; iip->iic_tfcr = SMC_EB; iip->iic_rfcr = SMC_EB; /* Set maximum receive size. */ iip->iic_mrblr = CPM_MAX_READ; /* Initialize Tx/Rx parameters. */ if (cpm_adap->reloc == 0) { volatile cpm8xx_t *cp = cpm_adap->cp; 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 = 0x80; /* Filter clock */ i2c->i2c_i2com = 0x01; /* Master mode */ /* Disable interrupts. */ i2c->i2c_i2cmr = 0; i2c->i2c_i2cer = 0xff; init_waitqueue_head(&iic_wait); /* Install interrupt handler. */ (*cpm_adap->setisr)(CPMVEC_I2C, cpm_iic_interrupt, (void *)i2c); } static int cpm_iic_shutdown(struct i2c_algo_8xx_data *cpm_adap) { volatile i2c8xx_t *i2c = cpm_adap->i2c; /* Shut down IIC. */ i2c->i2c_i2mod &= ~1; i2c->i2c_i2cmr = 0; i2c->i2c_i2cer = 0xff; return(0); } static void cpm_reset_iic_params(volatile iic_t *iip) { 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; iip->iic_rstate = 0; iip->iic_rdp = 0; iip->iic_rbptr = iip->iic_rbase; iip->iic_rbc = 0; iip->iic_rxtmp = 0; iip->iic_tstate = 0; iip->iic_tdp = 0; iip->iic_tbptr = iip->iic_tbase; iip->iic_tbc = 0; iip->iic_txtmp = 0; } #define BD_SC_NAK ((ushort)0x0004) /* NAK - did not respond */ #define BD_SC_OV ((ushort)0x0002) /* OV - receive overrun */ #define CPM_CR_CLOSE_RXBD ((ushort)0x0007) static void force_close(struct i2c_algo_8xx_data *cpm) { volatile i2c8xx_t *i2c = cpm->i2c; if (cpm->reloc == 0) { /* micro code disabled */ volatile cpm8xx_t *cp = cpm->cp; if (cpm_debug) printk("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; } /* Read from IIC... * abyte = address byte, with r/w flag already set */ static int cpm_iic_read(struct i2c_algo_8xx_data *cpm, u_char abyte, char *buf, int count) { volatile iic_t *iip = cpm->iip; volatile i2c8xx_t *i2c = cpm->i2c; volatile cpm8xx_t *cp = cpm->cp; volatile cbd_t *tbdf, *rbdf; u_char *tb; unsigned long flags, tmo; if (count >= CPM_MAX_READ) return -EINVAL; /* check for and use a microcode relocation patch */ if (cpm->reloc) { cpm_reset_iic_params(iip); } tbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_tbase]; rbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_rbase]; /* To read, we need an empty buffer of the proper length. * All that is used is the first byte for address, the remainder * is just used for timing (and doesn't really have to exist). */ tb = cpm->temp; tb = (u_char *)(((uint)tb + 15) & ~15); tb[0] = abyte; /* Device address byte w/rw flag */ flush_dcache_range((unsigned long)tb, (unsigned long)(tb+1)); if (cpm_debug) printk("cpm_iic_read(abyte=0x%x)\n", abyte); tbdf->cbd_bufaddr = __pa(tb); tbdf->cbd_datlen = count + 1; tbdf->cbd_sc = BD_SC_READY | BD_SC_LAST | BD_SC_WRAP | BD_IIC_START; iip->iic_mrblr = count +1; /* prevent excessive read, +1 is needed otherwise will the RXB interrupt come too early */ /* flush will invalidate too. */ flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); rbdf->cbd_datlen = 0; rbdf->cbd_bufaddr = __pa(buf); rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP| BD_SC_INTRPT; /* Chip bug, set enable here */ local_irq_save(flags); i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ i2c->i2c_i2cer = 0xff; i2c->i2c_i2mod |= 1; /* Enable */ i2c->i2c_i2com |= 0x80; /* Begin transmission */ /* Wait for IIC transfer */ tmo = interruptible_sleep_on_timeout(&iic_wait,3*HZ); local_irq_restore(flags); if(irq_flags & 0x14) printk("IIC read irq err:%x\n",(unsigned int) irq_flags); if (signal_pending(current) || !tmo){ force_close(cpm); if(cpm_debug) printk("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 */ udelay(4); i2c->i2c_i2mod &= ~1; #endif if (cpm_debug) { printk("tx sc %04x, rx sc %04x\n", tbdf->cbd_sc, rbdf->cbd_sc); } if (tbdf->cbd_sc & BD_SC_READY) { printk("IIC read; complete but tbuf ready\n"); force_close(cpm); printk("tx sc %04x, rx sc %04x\n", tbdf->cbd_sc, rbdf->cbd_sc); } if (tbdf->cbd_sc & BD_SC_NAK) { if (cpm_debug) printk("IIC read; no ack\n"); return -EREMOTEIO; } if (rbdf->cbd_sc & BD_SC_EMPTY) { /* force_close(cpm); */ if (cpm_debug){ printk("IIC read; complete but rbuf empty\n"); printk("tx sc %04x, rx sc %04x\n", tbdf->cbd_sc, rbdf->cbd_sc); } return -EREMOTEIO; } if (rbdf->cbd_sc & BD_SC_OV) { if (cpm_debug) printk("IIC read; Overrun\n"); return -EREMOTEIO;; } if (cpm_debug) printk("read %d bytes\n", rbdf->cbd_datlen); if (rbdf->cbd_datlen < count) { if (cpm_debug) printk("IIC read; short, wanted %d got %d\n", count, rbdf->cbd_datlen); return 0; } return count; } /* Write to IIC... * addr = address byte, with r/w flag already set */ static int cpm_iic_write(struct i2c_algo_8xx_data *cpm, u_char abyte, char *buf,int count) { volatile iic_t *iip = cpm->iip; volatile i2c8xx_t *i2c = cpm->i2c; volatile cpm8xx_t *cp = cpm->cp; volatile cbd_t *tbdf; u_char *tb; unsigned long flags, tmo; /* check for and use a microcode relocation patch */ if (cpm->reloc) { cpm_reset_iic_params(iip); } tb = cpm->temp; tb = (u_char *)(((uint)tb + 15) & ~15); *tb = abyte; /* Device address byte w/rw flag */ flush_dcache_range((unsigned long)tb, (unsigned long)(tb+1)); flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); if (cpm_debug) printk("cpm_iic_write(abyte=0x%x)\n", abyte); /* set up 2 descriptors */ tbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_tbase]; tbdf[0].cbd_bufaddr = __pa(tb); tbdf[0].cbd_datlen = 1; tbdf[0].cbd_sc = BD_SC_READY | BD_IIC_START; tbdf[1].cbd_bufaddr = __pa(buf); tbdf[1].cbd_datlen = count; tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP; /* Chip bug, set enable here */ local_irq_save(flags); i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ i2c->i2c_i2cer = 0xff; i2c->i2c_i2mod |= 1; /* Enable */ i2c->i2c_i2com |= 0x80; /* Begin transmission */ /* Wait for IIC transfer */ tmo = interruptible_sleep_on_timeout(&iic_wait,3*HZ); local_irq_restore(flags); if(irq_flags & 0x14) printk("IIC write irq err:%x\n",(unsigned int) irq_flags); if (signal_pending(current) || !tmo){ force_close(cpm); if(cpm_debug && !tmo) printk("IIC write: timeout!\n"); return -EIO; } #if 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 */ udelay(4); i2c->i2c_i2mod &= ~1; #endif if (cpm_debug) { printk("tx0 sc %04x, tx1 sc %04x\n", tbdf[0].cbd_sc, tbdf[1].cbd_sc); } if (tbdf->cbd_sc & BD_SC_NAK) { if (cpm_debug) printk("IIC write; no ack\n"); return 0; } if (tbdf->cbd_sc & BD_SC_READY) { if (cpm_debug) printk("IIC write; complete but tbuf ready\n"); return 0; } return count; } /* See if an IIC address exists.. * addr = 7 bit address, unshifted */ static int cpm_iic_tryaddress(struct i2c_algo_8xx_data *cpm, int addr) { volatile iic_t *iip = cpm->iip; volatile i2c8xx_t *i2c = cpm->i2c; volatile cpm8xx_t *cp = cpm->cp; volatile cbd_t *tbdf, *rbdf; u_char *tb; unsigned long flags, len, tmo; if (cpm_debug > 1) printk("cpm_iic_tryaddress(cpm=%p,addr=%d)\n", cpm, addr); /* check for and use a microcode relocation patch */ if (cpm->reloc) { cpm_reset_iic_params(iip); } if (cpm_debug && addr == 0) { printk("iip %p, dp_addr 0x%x\n", cpm->iip, cpm->dp_addr); printk("iic_tbase %d, r_tbase %d\n", iip->iic_tbase, r_tbase); } tbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_tbase]; rbdf = (cbd_t *)&cp->cp_dpmem[iip->iic_rbase]; tb = cpm->temp; tb = (u_char *)(((uint)tb + 15) & ~15); /* do a simple read */ tb[0] = (addr << 1) | 1; /* device address (+ read) */ len = 2; flush_dcache_range((unsigned long)tb, (unsigned long)(tb+2)); tbdf->cbd_bufaddr = __pa(tb); tbdf->cbd_datlen = len; tbdf->cbd_sc = BD_SC_READY | BD_SC_LAST | BD_SC_WRAP | BD_IIC_START; rbdf->cbd_datlen = 0; rbdf->cbd_bufaddr = __pa(tb+2); rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP | BD_SC_INTRPT; local_irq_save(flags); i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ i2c->i2c_i2cer = 0xff; i2c->i2c_i2mod |= 1; /* Enable */ i2c->i2c_i2com |= 0x80; /* Begin transmission */ if (cpm_debug > 1) printk("about to sleep\n"); /* wait for IIC transfer */ tmo = interruptible_sleep_on_timeout(&iic_wait,3*HZ); local_irq_restore(flags); #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 */ udelay(4); i2c->i2c_i2mod &= ~1; #endif if (signal_pending(current) || !tmo){ force_close(cpm); if(cpm_debug && !tmo) printk("IIC tryaddress: timeout!\n"); return -EIO; } if (cpm_debug > 1) printk("back from sleep\n"); if (tbdf->cbd_sc & BD_SC_NAK) { if (cpm_debug > 1) printk("IIC try; no ack\n"); return 0; } if (tbdf->cbd_sc & BD_SC_READY) { printk("IIC try; complete but tbuf ready\n"); } return 1; } static int cpm_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg msgs[], int num) { struct i2c_algo_8xx_data *adap = i2c_adap->algo_data; struct i2c_msg *pmsg; int i, ret; u_char addr; for (i = 0; i < num; i++) { pmsg = &msgs[i]; if (cpm_debug) printk("i2c-algo-8xx.o: " "#%d addr=0x%x flags=0x%x len=%d\n buf=%lx\n", i, pmsg->addr, pmsg->flags, pmsg->len, (unsigned long)pmsg->buf); addr = pmsg->addr << 1; if (pmsg->flags & I2C_M_RD ) addr |= 1; if (pmsg->flags & I2C_M_REV_DIR_ADDR ) addr ^= 1; if (!(pmsg->flags & I2C_M_NOSTART)) { } if (pmsg->flags & I2C_M_RD ) { /* read bytes into buffer*/ ret = cpm_iic_read(adap, addr, pmsg->buf, pmsg->len); if (cpm_debug) printk("i2c-algo-8xx.o: read %d bytes\n", ret); if (ret < pmsg->len ) { return (ret<0)? ret : -EREMOTEIO; } } else { /* write bytes from buffer */ ret = cpm_iic_write(adap, addr, pmsg->buf, pmsg->len); if (cpm_debug) printk("i2c-algo-8xx.o: wrote %d\n", ret); if (ret < pmsg->len ) { return (ret<0) ? ret : -EREMOTEIO; } } } return (num); } #define I2C_BITRATE 0x070f static int algo_control(struct i2c_adapter *adapter, unsigned int cmd, unsigned long arg) { struct i2c_algo_8xx_data *adap = adapter->algo_data; volatile i2c8xx_t *i2c = adap->i2c; unsigned char brg; bd_t *bd = (bd_t *)__res; switch(cmd){ case I2C_BITRATE: brg = (unsigned char) (bd->bi_intfreq/(32*2*arg) -3); printk("IntFreq: %lu I2C brg: %lu\n", bd->bi_intfreq, (unsigned long)brg); i2c->i2c_i2brg = brg; return 0; break; default: return -EINVAL; } } static u32 cpm_func(struct i2c_adapter *adap) { return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING; } /* -----exported algorithm data: ------------------------------------- */ static struct i2c_algorithm cpm_algo = { "MPX8XX CPM algorithm", I2C_ALGO_MPC8XX, cpm_xfer, NULL, NULL, /* slave_xmit */ NULL, /* slave_recv */ algo_control, /* ioctl */ cpm_func, /* functionality */ }; /* * registering functions to load algorithms at runtime */ int i2c_8xx_add_bus(struct i2c_adapter *adap) { int i; struct i2c_algo_8xx_data *cpm_adap = adap->algo_data; if (cpm_debug) printk("i2c-algo-8xx.o: hw routines for %s registered.\n", adap->name); /* register new adapter to i2c module... */ adap->id |= cpm_algo.id; adap->algo = &cpm_algo; #ifdef MODULE MOD_INC_USE_COUNT; #endif i2c_add_adapter(adap); cpm_iic_init(cpm_adap); /* scan bus */ if (cpm_scan) { printk(KERN_INFO " i2c-algo-8xx.o: scanning bus %s...\n", adap->name); for (i = 0; i < 128; i++) { if (cpm_iic_tryaddress(cpm_adap, i)) { printk("(%02x)",i<<1); } } printk("\n"); } return 0; } int i2c_8xx_del_bus(struct i2c_adapter *adap) { int res; struct i2c_algo_8xx_data *cpm_adap = adap->algo_data; cpm_iic_shutdown(cpm_adap); if ((res = i2c_del_adapter(adap)) < 0) return res; printk("i2c-algo-8xx.o: adapter unregistered: %s\n",adap->name); #ifdef MODULE MOD_DEC_USE_COUNT; #endif return 0; } EXPORT_SYMBOL(i2c_8xx_add_bus); EXPORT_SYMBOL(i2c_8xx_del_bus); int __init i2c_algo_8xx_init (void) { printk("i2c-algo-8xx.o: i2c mpc8xx algorithm module\n"); return 0; } #ifdef MODULE MODULE_AUTHOR("Brad Parker <brad@heeltoe.com>"); MODULE_DESCRIPTION("I2C-Bus MPC8XX algorithm"); int init_module(void) { return i2c_algo_8xx_init(); } void cleanup_module(void) { } #endif ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-11 9:12 ` Joakim Tjernlund @ 2002-10-11 9:56 ` bart 2002-10-11 12:02 ` Stephan Linke 2002-10-15 16:57 ` Tom Rini 2 siblings, 0 replies; 30+ messages in thread From: bart @ 2002-10-11 9:56 UTC (permalink / raw) To: joakim.tjernlund; +Cc: linuxppc-embedded Hi Joakim, > OK, here it is. > Thanks > Perhaps someone can add it to the ppctree? > As far as I understand is the i2c not 'realy' a part of the Linux source (I think on http://www2.lm-sensors.nu you find the I2C maintainers which results in all kind off problems with the drivers :( Cheers, Bart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-11 9:12 ` Joakim Tjernlund 2002-10-11 9:56 ` bart @ 2002-10-11 12:02 ` Stephan Linke 2002-10-11 12:14 ` bart 2002-10-11 12:44 ` Joakim Tjernlund 2002-10-15 16:57 ` Tom Rini 2 siblings, 2 replies; 30+ messages in thread From: Stephan Linke @ 2002-10-11 12:02 UTC (permalink / raw) To: joakim.tjernlund; +Cc: Linuxppc-Embedded Hi, I had a look at you code. Some of the changes I already did in my code. :) I couldn't find any thing that looks like it's fixing the memory problem that you mentioned. I'm looking for a memory problem by my self and I wonder what you might have figured out. Could you tell me more details? Regards, Stephan > -----Original Message----- > From: owner-linuxppc-embedded@lists.linuxppc.org > [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Joakim > Tjernlund > Sent: Freitag, 11. Oktober 2002 11:12 > To: bart@ardistech.com > Cc: linuxppc-embedded@lists.linuxppc.org > Subject: RE: 8xx i2c refers to unspecified chip errata > > > OK, here it is. > > Perhaps someone can add it to the ppctree? > > Jocke > > > > > > > Hi Joakim, > > > > > Anyway I have fixed the bugs in i2c-algo-8xx.c driver and > it's working great for me > > > so I think I will stick with it for the time being. > > > > > Could you please post the fixes on the list? I also might want > to use them. > > > > Thanks, > > Bart > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-11 12:02 ` Stephan Linke @ 2002-10-11 12:14 ` bart 2002-10-11 12:31 ` Stephan Linke 2002-10-11 12:44 ` Joakim Tjernlund 1 sibling, 1 reply; 30+ messages in thread From: bart @ 2002-10-11 12:14 UTC (permalink / raw) To: Stephan Linke; +Cc: Linuxppc-Embedded Hi Stephan, > I had a look at you code. Some of the changes I already did in my code. :) > I couldn't find any thing that looks like it's fixing the memory problem > that you mentioned. I'm looking for a memory problem by my self and I wonder > what you might have figured out. > You're sure it not a cache invalidate problem you're looking at? Cheers, Bart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-11 12:14 ` bart @ 2002-10-11 12:31 ` Stephan Linke 2002-10-11 12:46 ` Joakim Tjernlund 0 siblings, 1 reply; 30+ messages in thread From: Stephan Linke @ 2002-10-11 12:31 UTC (permalink / raw) To: bart, joakim.tjernlund; +Cc: Linuxppc-Embedded Hi Bart and Joakim, Well. No, I'm not shure. But I see what you mean Bart. :) I'll see what happens now. And I have a question to Joakim. In your code you wrote (cpm_iic_init): i2c->i2c_i2mod = 0x80; /* Filter clock */ I think this is not what you intended. I didn't find that bit (bit 0) in my 862 manual. But there's the FLT flag (bit 4) that matches your comment. So I think It should be: i2c->i2c_i2mod = 0x08; /* Filter clock */ Thanks, Stephan > -----Original Message----- > From: bart [mailto:bart]On Behalf Of bart@ardistech.com > Sent: Freitag, 11. Oktober 2002 14:15 > To: Stephan Linke > Cc: Linuxppc-Embedded > Subject: Re: 8xx i2c refers to unspecified chip errata > > > Hi Stephan, > > > I had a look at you code. Some of the changes I already did in > my code. :) > > I couldn't find any thing that looks like it's fixing the memory problem > > that you mentioned. I'm looking for a memory problem by my self > and I wonder > > what you might have figured out. > > > You're sure it not a cache invalidate problem you're looking at? > > Cheers, > Bart > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-11 12:31 ` Stephan Linke @ 2002-10-11 12:46 ` Joakim Tjernlund 0 siblings, 0 replies; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-11 12:46 UTC (permalink / raw) To: Stephan Linke, bart; +Cc: Linuxppc-Embedded > > > Hi Bart and Joakim, > > Well. No, I'm not shure. But I see what you mean Bart. :) I'll see what > happens now. > > And I have a question to Joakim. In your code you wrote (cpm_iic_init): > > i2c->i2c_i2mod = 0x80; /* Filter clock */ > > I think this is not what you intended. I didn't find that bit (bit 0) in my > 862 manual. But there's the FLT flag (bit 4) that matches your comment. So I > think It should be: > > i2c->i2c_i2mod = 0x08; /* Filter clock */ You are right Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-11 12:02 ` Stephan Linke 2002-10-11 12:14 ` bart @ 2002-10-11 12:44 ` Joakim Tjernlund 2002-10-11 12:55 ` bart 1 sibling, 1 reply; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-11 12:44 UTC (permalink / raw) To: Stephan Linke; +Cc: Linuxppc-Embedded Hi, Look in cpm_iic_read() for: /* flush will invalidate too. */ flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); You can't just do invalidate_dcache_range() since it will invalidate more than your buffer if it's not cache line aligned. Therefore you must flush to memory first and then invalidate. But you don't need an explicit invalidate_dcache_range() since flush_dcache_range() will flush to memory AND invalidate. Jocke > > Hi, > > I had a look at you code. Some of the changes I already did in my code. :) > I couldn't find any thing that looks like it's fixing the memory problem > that you mentioned. I'm looking for a memory problem by my self and I wonder > what you might have figured out. Could you tell me more details? > > Regards, Stephan > > > -----Original Message----- > > From: owner-linuxppc-embedded@lists.linuxppc.org > > [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Joakim > > Tjernlund > > Sent: Freitag, 11. Oktober 2002 11:12 > > To: bart@ardistech.com > > Cc: linuxppc-embedded@lists.linuxppc.org > > Subject: RE: 8xx i2c refers to unspecified chip errata > > > > > > OK, here it is. > > > > Perhaps someone can add it to the ppctree? > > > > Jocke > > > > > > > > > > > Hi Joakim, > > > > > > > Anyway I have fixed the bugs in i2c-algo-8xx.c driver and > > it's working great for me > > > > so I think I will stick with it for the time being. > > > > > > > Could you please post the fixes on the list? I also might want > > to use them. > > > > > > Thanks, > > > Bart > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-11 12:44 ` Joakim Tjernlund @ 2002-10-11 12:55 ` bart 2002-10-11 13:10 ` Joakim Tjernlund 0 siblings, 1 reply; 30+ messages in thread From: bart @ 2002-10-11 12:55 UTC (permalink / raw) To: joakim.tjernlund; +Cc: Stephan Linke, Linuxppc-Embedded Hi, > Look in cpm_iic_read() for: > /* flush will invalidate too. */ > flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); > > You can't just do invalidate_dcache_range() since it will invalidate more than your buffer > In my case it did invalidate the stack :( > if it's not cache line aligned. Therefore you must flush to memory first and then invalidate. > But you don't need an explicit invalidate_dcache_range() since flush_dcache_range() will flush to > memory AND invalidate. > Better would be to have a special DMA region for this. Or as Dan suggest forget the whole CPM IIC and do it by software. Cheers, Bart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-11 12:55 ` bart @ 2002-10-11 13:10 ` Joakim Tjernlund 0 siblings, 0 replies; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-11 13:10 UTC (permalink / raw) To: bart; +Cc: Stephan Linke, Linuxppc-Embedded > Hi, > > > Look in cpm_iic_read() for: > > /* flush will invalidate too. */ > > flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); > > > > You can't just do invalidate_dcache_range() since it will invalidate more than your buffer > > > In my case it did invalidate the stack :( Me too, it was a major PITA to hunt it down. Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-11 9:12 ` Joakim Tjernlund 2002-10-11 9:56 ` bart 2002-10-11 12:02 ` Stephan Linke @ 2002-10-15 16:57 ` Tom Rini 2002-10-22 9:15 ` Joakim Tjernlund 2 siblings, 1 reply; 30+ messages in thread From: Tom Rini @ 2002-10-15 16:57 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: bart, linuxppc-embedded On Fri, Oct 11, 2002 at 11:12:02AM +0200, Joakim Tjernlund wrote: > OK, here it is. > > Perhaps someone can add it to the ppctree? If you can submit this as a patch vs what's in the i2c CVS tree or the ppctree, than yes, this can be committed there, and to the ppctrees. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-15 16:57 ` Tom Rini @ 2002-10-22 9:15 ` Joakim Tjernlund 2002-10-24 16:10 ` Tom Rini 0 siblings, 1 reply; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-22 9:15 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc-embedded, sensors > On Fri, Oct 11, 2002 at 11:12:02AM +0200, Joakim Tjernlund wrote: > > > OK, here it is. > > > > Perhaps someone can add it to the ppctree? > > If you can submit this as a patch vs what's in the i2c CVS tree or the > ppctree, than yes, this can be committed there, and to the ppctrees. Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c Tom, do you look after 8xx_io/enet.c? I sent a patch to the emmbedded list yesterday that does away with an expensive memcpy. Jocke --- i2c-algo-8xx.c Mon Sep 30 16:20:42 2002 +++ i2c-algo-8xx.c.clean Tue Oct 22 10:49:33 2002 @@ -7,15 +7,12 @@ * Brad Parker (brad@heeltoe.com) */ -// XXX todo -// timeout sleep? - /* $Id$ */ #include <linux/kernel.h> #include <linux/module.h> #include <linux/delay.h> -#include <linux/malloc.h> +#include <linux/slab.h> #include <linux/version.h> #include <linux/init.h> #include <asm/uaccess.h> @@ -30,25 +27,25 @@ #include <linux/i2c-algo-8xx.h> #define CPM_MAX_READ 513 - +/* #define I2C_CHIP_ERRATA */ /* Try uncomment this if you have an older CPU(earlier than rev D4) */ static wait_queue_head_t iic_wait; static ushort r_tbase, r_rbase; int cpm_scan = 0; -int cpm_debug = 1; +int cpm_debug = 0; -static void -cpm_iic_interrupt(void *dev_id) +static void +cpm_iic_interrupt(void *dev_id, struct pt_regs *regs) { volatile i2c8xx_t *i2c = (i2c8xx_t *)dev_id; - if (cpm_debug > 1) printk("cpm_iic_interrupt(dev_id=%p)\n", dev_id); - - /* Chip errata, clear enable. - */ - i2c->i2c_i2mod = 0; - +#if 0 + /* Chip errata, clear enable. This is not needed on rev D4 CPUs */ + /* This should probably be removed and replaced by I2C_CHIP_ERRATA stuff */ + /* Someone with a buggy CPU needs to confirm that */ + i2c->i2c_i2mod &= ~1; +#endif /* Clear interrupt. */ i2c->i2c_i2cer = 0xff; @@ -63,6 +60,8 @@ { volatile iic_t *iip = cpm_adap->iip; volatile i2c8xx_t *i2c = cpm_adap->i2c; + unsigned char brg; + bd_t *bd = (bd_t *)__res; if (cpm_debug) printk("cpm_iic_init()\n"); @@ -101,15 +100,24 @@ 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 = 0x34; + i2c->i2c_i2add = 0xfe; - /* Make clock run maximum slow. + /* Make clock run at 60 KHz. */ - i2c->i2c_i2brg = 7; + brg = (unsigned char) (bd->bi_intfreq/(32*2*60000) -3); + i2c->i2c_i2brg = brg; + + i2c->i2c_i2mod = 0x00; + i2c->i2c_i2com = 0x01; /* Master mode */ /* Disable interrupts. */ @@ -131,7 +139,7 @@ /* Shut down IIC. */ - i2c->i2c_i2mod = 0; + i2c->i2c_i2mod &= ~1; i2c->i2c_i2cmr = 0; i2c->i2c_i2cer = 0xff; @@ -151,22 +159,24 @@ iip->iic_rstate = 0; iip->iic_rdp = 0; - iip->iic_rbptr = 0; + iip->iic_rbptr = iip->iic_rbase; iip->iic_rbc = 0; iip->iic_rxtmp = 0; iip->iic_tstate = 0; iip->iic_tdp = 0; - iip->iic_tbptr = 0; + iip->iic_tbptr = iip->iic_tbase; iip->iic_tbc = 0; iip->iic_txtmp = 0; } #define BD_SC_NAK ((ushort)0x0004) /* NAK - did not respond */ +#define BD_SC_OV ((ushort)0x0002) /* OV - receive overrun */ #define CPM_CR_CLOSE_RXBD ((ushort)0x0007) static void force_close(struct i2c_algo_8xx_data *cpm) { - if (cpm->reloc == 0) { + volatile i2c8xx_t *i2c = cpm->i2c; + if (cpm->reloc == 0) { /* micro code disabled */ volatile cpm8xx_t *cp = cpm->cp; if (cpm_debug) printk("force_close()\n"); @@ -176,6 +186,8 @@ while (cp->cp_cpcr & CPM_CR_FLG); } + i2c->i2c_i2cmr = 0x00; /* Disable all interrupts */ + i2c->i2c_i2cer = 0xff; } @@ -190,7 +202,7 @@ volatile cpm8xx_t *cp = cpm->cp; volatile cbd_t *tbdf, *rbdf; u_char *tb; - unsigned long flags; + unsigned long flags, tmo; if (count >= CPM_MAX_READ) return -EINVAL; @@ -207,68 +219,104 @@ * All that is used is the first byte for address, the remainder * is just used for timing (and doesn't really have to exist). */ - if (cpm->reloc) { - cpm_reset_iic_params(iip); - } tb = cpm->temp; tb = (u_char *)(((uint)tb + 15) & ~15); tb[0] = abyte; /* Device address byte w/rw flag */ - flush_dcache_range(tb, tb+1); - + flush_dcache_range((unsigned long)tb, (unsigned long)(tb+1)); if (cpm_debug) printk("cpm_iic_read(abyte=0x%x)\n", abyte); tbdf->cbd_bufaddr = __pa(tb); tbdf->cbd_datlen = count + 1; tbdf->cbd_sc = - BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | + BD_SC_READY | BD_SC_LAST | BD_SC_WRAP | BD_IIC_START; + iip->iic_mrblr = count +1; /* prevent excessive read, +1 + is needed otherwise will the + RXB interrupt come too early */ + + /* flush will invalidate too. */ + flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); + rbdf->cbd_datlen = 0; rbdf->cbd_bufaddr = __pa(buf); - rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP; - - /* Chip bug, set enable here */ - save_flags(flags); cli(); - i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ - i2c->i2c_i2cer = 0xff; - i2c->i2c_i2mod = 1; /* Enable */ - i2c->i2c_i2com = 0x81; /* Start master */ + rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP| BD_SC_INTRPT; + if(count > 16){ + /* Chip bug, set enable here */ + local_irq_save(flags); + i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ + i2c->i2c_i2cer = 0xff; + i2c->i2c_i2mod |= 1; /* Enable */ + i2c->i2c_i2com |= 0x80; /* Begin transmission */ + + /* Wait for IIC transfer */ + tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ); + local_irq_restore(flags); + } 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 */ + } - /* Wait for IIC transfer */ - interruptible_sleep_on(&iic_wait); - restore_flags(flags); - if (signal_pending(current)) + if (signal_pending(current) || !tmo){ + force_close(cpm); + if(cpm_debug) + printk("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 */ + udelay(4); + i2c->i2c_i2mod &= ~1; +#endif if (cpm_debug) { printk("tx sc %04x, rx sc %04x\n", tbdf->cbd_sc, rbdf->cbd_sc); } + if (tbdf->cbd_sc & BD_SC_READY) { + printk("IIC read; complete but tbuf ready\n"); + force_close(cpm); + printk("tx sc %04x, rx sc %04x\n", + tbdf->cbd_sc, rbdf->cbd_sc); + } + if (tbdf->cbd_sc & BD_SC_NAK) { - printk("IIC read; no ack\n"); - return 0; + if (cpm_debug) + printk("IIC read; no ack\n"); + return -EREMOTEIO; } if (rbdf->cbd_sc & BD_SC_EMPTY) { - printk("IIC read; complete but rbuf empty\n"); - force_close(cpm); - printk("tx sc %04x, rx sc %04x\n", - tbdf->cbd_sc, rbdf->cbd_sc); + /* force_close(cpm); */ + if (cpm_debug){ + printk("IIC read; complete but rbuf empty\n"); + printk("tx sc %04x, rx sc %04x\n", + tbdf->cbd_sc, rbdf->cbd_sc); + } + return -EREMOTEIO; + } + + if (rbdf->cbd_sc & BD_SC_OV) { + if (cpm_debug) + printk("IIC read; Overrun\n"); + return -EREMOTEIO;; } if (cpm_debug) printk("read %d bytes\n", rbdf->cbd_datlen); if (rbdf->cbd_datlen < count) { - printk("IIC read; short, wanted %d got %d\n", - count, rbdf->cbd_datlen); + if (cpm_debug) + printk("IIC read; short, wanted %d got %d\n", + count, rbdf->cbd_datlen); return 0; } - - invalidate_dcache_range(buf, buf+count); - return count; } @@ -283,7 +331,7 @@ volatile cpm8xx_t *cp = cpm->cp; volatile cbd_t *tbdf; u_char *tb; - unsigned long flags; + unsigned long flags, tmo; /* check for and use a microcode relocation patch */ if (cpm->reloc) { @@ -293,8 +341,8 @@ tb = (u_char *)(((uint)tb + 15) & ~15); *tb = abyte; /* Device address byte w/rw flag */ - flush_dcache_range(tb, tb+1); - flush_dcache_range(buf, buf+count); + flush_dcache_range((unsigned long)tb, (unsigned long)(tb+1)); + flush_dcache_range((unsigned long)buf, (unsigned long)(buf+count)); if (cpm_debug) printk("cpm_iic_write(abyte=0x%x)\n", abyte); @@ -309,31 +357,53 @@ tbdf[1].cbd_datlen = count; tbdf[1].cbd_sc = BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | BD_SC_WRAP; - /* Chip bug, set enable here */ - save_flags(flags); cli(); - i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ - i2c->i2c_i2cer = 0xff; - i2c->i2c_i2mod = 1; /* Enable */ - i2c->i2c_i2com = 0x81; /* Start master */ + if(count > 16){ + /* Chip bug, set enable here */ + local_irq_save(flags); + i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ + i2c->i2c_i2cer = 0xff; + i2c->i2c_i2mod |= 1; /* Enable */ + i2c->i2c_i2com |= 0x80; /* Begin transmission */ + + /* Wait for IIC transfer */ + tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ); + local_irq_restore(flags); + } 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 */ + } - /* Wait for IIC transfer */ - interruptible_sleep_on(&iic_wait); - restore_flags(flags); - if (signal_pending(current)) + if (signal_pending(current) || !tmo){ + force_close(cpm); + if(cpm_debug && !tmo) + printk("IIC write: timeout!\n"); return -EIO; - + } + +#if 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 */ + udelay(4); + i2c->i2c_i2mod &= ~1; +#endif if (cpm_debug) { printk("tx0 sc %04x, tx1 sc %04x\n", tbdf[0].cbd_sc, tbdf[1].cbd_sc); } if (tbdf->cbd_sc & BD_SC_NAK) { - printk("IIC write; no ack\n"); + if (cpm_debug) + printk("IIC write; no ack\n"); return 0; } if (tbdf->cbd_sc & BD_SC_READY) { - printk("IIC write; complete but tbuf ready\n"); + if (cpm_debug) + printk("IIC write; complete but tbuf ready\n"); return 0; } @@ -351,7 +421,7 @@ volatile cpm8xx_t *cp = cpm->cp; volatile cbd_t *tbdf, *rbdf; u_char *tb; - unsigned long flags, len; + unsigned long flags, len, tmo; if (cpm_debug > 1) printk("cpm_iic_tryaddress(cpm=%p,addr=%d)\n", cpm, addr); @@ -376,31 +446,43 @@ tb[0] = (addr << 1) | 1; /* device address (+ read) */ len = 2; - flush_dcache_range(tb, tb+1); + flush_dcache_range((unsigned long)tb, (unsigned long)(tb+2)); tbdf->cbd_bufaddr = __pa(tb); tbdf->cbd_datlen = len; tbdf->cbd_sc = - BD_SC_READY | BD_SC_INTRPT | BD_SC_LAST | + BD_SC_READY | BD_SC_LAST | BD_SC_WRAP | BD_IIC_START; rbdf->cbd_datlen = 0; rbdf->cbd_bufaddr = __pa(tb+2); - rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP; + rbdf->cbd_sc = BD_SC_EMPTY | BD_SC_WRAP | BD_SC_INTRPT; - save_flags(flags); cli(); + local_irq_save(flags); i2c->i2c_i2cmr = 0x13; /* Enable some interupts */ i2c->i2c_i2cer = 0xff; - i2c->i2c_i2mod = 1; /* Enable */ - i2c->i2c_i2com = 0x81; /* Start master */ + i2c->i2c_i2mod |= 1; /* Enable */ + i2c->i2c_i2com |= 0x80; /* Begin transmission */ if (cpm_debug > 1) printk("about to sleep\n"); /* wait for IIC transfer */ - interruptible_sleep_on(&iic_wait); - restore_flags(flags); - if (signal_pending(current)) + tmo = interruptible_sleep_on_timeout(&iic_wait,1*HZ); + local_irq_restore(flags); + +#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 */ + udelay(4); + i2c->i2c_i2mod &= ~1; +#endif + + if (signal_pending(current) || !tmo){ + force_close(cpm); + if(cpm_debug && !tmo) + printk("IIC tryaddress: timeout!\n"); return -EIO; + } if (cpm_debug > 1) printk("back from sleep\n"); @@ -430,8 +512,8 @@ if (cpm_debug) printk("i2c-algo-8xx.o: " - "#%d addr=0x%x flags=0x%x len=%d\n", - i, pmsg->addr, pmsg->flags, pmsg->len); + "#%d addr=0x%x flags=0x%x len=%d\n buf=%lx\n", + i, pmsg->addr, pmsg->flags, pmsg->len, (unsigned long)pmsg->buf); addr = pmsg->addr << 1; if (pmsg->flags & I2C_M_RD ) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-22 9:15 ` Joakim Tjernlund @ 2002-10-24 16:10 ` Tom Rini 2002-10-24 18:21 ` Joakim Tjernlund 0 siblings, 1 reply; 30+ messages in thread From: Tom Rini @ 2002-10-24 16:10 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: linuxppc-embedded, sensors On Tue, Oct 22, 2002 at 11:15:38AM +0200, Joakim Tjernlund wrote: > > > On Fri, Oct 11, 2002 at 11:12:02AM +0200, Joakim Tjernlund wrote: > > > > > OK, here it is. > > > > > > Perhaps someone can add it to the ppctree? > > > > If you can submit this as a patch vs what's in the i2c CVS tree or the > > ppctree, than yes, this can be committed there, and to the ppctrees. > > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c Can you please split this into logical chunks, or give me a list of each fix in here? Thanks. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-24 16:10 ` Tom Rini @ 2002-10-24 18:21 ` Joakim Tjernlund 2002-11-01 11:01 ` Joakim Tjernlund 2002-11-17 20:51 ` Mark D. Studebaker 0 siblings, 2 replies; 30+ messages in thread From: Joakim Tjernlund @ 2002-10-24 18:21 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc-embedded, sensors > > > > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c > > Can you please split this into logical chunks, or give me a list of each > fix in here? Thanks. ohh, kind of hard to remember all that went into that patch. The path has evoled over many days, but I can try summarize. I have tested this code pretty well it does not fail for me. Speed has been between 10-150KHz. The old code fails as soon you start to stress it a little. - replace invalidate_dcache_range with flush_dcache_range, since buffers are NOT cache aligned. flush will write to memory AND invalidate the cache. - move the chip errata stuff from irq routine into read/write routines. Made it default off since it causes lock ups on my I2C device. I think it causes a too short STOP condition. If enabled I2C will behave better than before, but may still cause problems if the read/write is interrupted with a signal while microcode is enabled. - set default speed to 60 KHz instead. - missing/faulty initialization of parameter ram when I2C micro patch is active. - replaced assingments with mask operations with relevant bits. Example: /* Shut down IIC. */ i2c->i2c_i2mod = 0; i2c->i2c_i2mod &= ~1; - When reading from I2C device, let the receive BD generate interrupt instead of the dummy trasmit. This is important since the TX interrupt will be too early sometimes, before the RX BD has closed. There is one case where the RX irq is before the TX irq, if iic_mrblr is set to match the number of bytes to read. Therefore must the iic_mrblr be one byte larger than the expected number of bytes. - busy wait for small transfers since it's faster. - save_flags(flags); cli(); cleanups - interruptible_sleep_on_timeout() instead of interruptible_sleep_on() so it won't hang forever if an irq is lost. Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-10-24 18:21 ` Joakim Tjernlund @ 2002-11-01 11:01 ` Joakim Tjernlund 2002-11-01 19:19 ` Tom Rini 2002-11-17 20:51 ` Mark D. Studebaker 1 sibling, 1 reply; 30+ messages in thread From: Joakim Tjernlund @ 2002-11-01 11:01 UTC (permalink / raw) To: Tom Rini; +Cc: linuxppc-embedded, sensors Hi Tom Will you apply this patch? No problems reported so far. Jocke > > > > > > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c > > > > Can you please split this into logical chunks, or give me a list of each > > fix in here? Thanks. > > ohh, kind of hard to remember all that went into that patch. The path > has evoled over many days, but I can try summarize. I have tested this code > pretty well it does not fail for me. Speed has been between 10-150KHz. The > old code fails as soon you start to stress it a little. > > - replace invalidate_dcache_range with flush_dcache_range, since buffers are > NOT cache aligned. flush will write to memory AND invalidate the cache. > > - move the chip errata stuff from irq routine into read/write routines. Made > it default off since it causes lock ups on my I2C device. I think it causes > a too short STOP condition. If enabled I2C will behave better than before, but > may still cause problems if the read/write is interrupted with a signal while > microcode is enabled. > > - set default speed to 60 KHz instead. > > - missing/faulty initialization of parameter ram when I2C micro patch is active. > > - replaced assingments with mask operations with relevant bits. Example: > /* Shut down IIC. */ > i2c->i2c_i2mod = 0; > i2c->i2c_i2mod &= ~1; > > - When reading from I2C device, let the receive BD generate interrupt instead of > the dummy trasmit. This is important since the TX interrupt will be too early sometimes, before > the RX BD has closed. There is one case where the RX irq is before the TX irq, if iic_mrblr is set > to match the number of bytes to read. Therefore must the iic_mrblr be one byte larger than > the expected number of bytes. > > - busy wait for small transfers since it's faster. > > - save_flags(flags); cli(); cleanups > > - interruptible_sleep_on_timeout() instead of interruptible_sleep_on() so it won't hang forever if an > irq is lost. > > Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-01 11:01 ` Joakim Tjernlund @ 2002-11-01 19:19 ` Tom Rini 0 siblings, 0 replies; 30+ messages in thread From: Tom Rini @ 2002-11-01 19:19 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: linuxppc-embedded, sensors On Fri, Nov 01, 2002 at 12:01:45PM +0100, Joakim Tjernlund wrote: > Hi Tom > > Will you apply this patch? No problems reported so far. I will try and do this next week. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-10-24 18:21 ` Joakim Tjernlund 2002-11-01 11:01 ` Joakim Tjernlund @ 2002-11-17 20:51 ` Mark D. Studebaker 2002-11-17 21:44 ` Joakim Tjernlund 1 sibling, 1 reply; 30+ messages in thread From: Mark D. Studebaker @ 2002-11-17 20:51 UTC (permalink / raw) To: joakim.tjernlund; +Cc: Tom Rini, linuxppc-embedded, sensors Tom + Joakim, we're doing a release soon over here at sensors/i2c, do you want this checked in as-is, with mods, or not at all? Joakim Tjernlund wrote: > > > > > > > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c > > > > Can you please split this into logical chunks, or give me a list of each > > fix in here? Thanks. > > ohh, kind of hard to remember all that went into that patch. The path > has evoled over many days, but I can try summarize. I have tested this code > pretty well it does not fail for me. Speed has been between 10-150KHz. The > old code fails as soon you start to stress it a little. > > - replace invalidate_dcache_range with flush_dcache_range, since buffers are > NOT cache aligned. flush will write to memory AND invalidate the cache. > > - move the chip errata stuff from irq routine into read/write routines. Made > it default off since it causes lock ups on my I2C device. I think it causes > a too short STOP condition. If enabled I2C will behave better than before, but > may still cause problems if the read/write is interrupted with a signal while > microcode is enabled. > > - set default speed to 60 KHz instead. > > - missing/faulty initialization of parameter ram when I2C micro patch is active. > > - replaced assingments with mask operations with relevant bits. Example: > /* Shut down IIC. */ > i2c->i2c_i2mod = 0; > i2c->i2c_i2mod &= ~1; > > - When reading from I2C device, let the receive BD generate interrupt instead of > the dummy trasmit. This is important since the TX interrupt will be too early sometimes, before > the RX BD has closed. There is one case where the RX irq is before the TX irq, if iic_mrblr is set > to match the number of bytes to read. Therefore must the iic_mrblr be one byte larger than > the expected number of bytes. > > - busy wait for small transfers since it's faster. > > - save_flags(flags); cli(); cleanups > > - interruptible_sleep_on_timeout() instead of interruptible_sleep_on() so it won't hang forever if an > irq is lost. > > Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-17 20:51 ` Mark D. Studebaker @ 2002-11-17 21:44 ` Joakim Tjernlund 2002-11-18 14:10 ` Tom Rini 0 siblings, 1 reply; 30+ messages in thread From: Joakim Tjernlund @ 2002-11-17 21:44 UTC (permalink / raw) To: Mark D. Studebaker; +Cc: Tom Rini, linuxppc-embedded, sensors As-is for me. No problems reported to me. Joakim > Tom + Joakim, > we're doing a release soon over here at sensors/i2c, > do you want this checked in as-is, with mods, or not at all? > > Joakim Tjernlund wrote: > > > > > > > > > > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c > > > > > > Can you please split this into logical chunks, or give me a list of each > > > fix in here? Thanks. > > > > ohh, kind of hard to remember all that went into that patch. The path > > has evoled over many days, but I can try summarize. I have tested this code > > pretty well it does not fail for me. Speed has been between 10-150KHz. The > > old code fails as soon you start to stress it a little. > > > > - replace invalidate_dcache_range with flush_dcache_range, since buffers are > > NOT cache aligned. flush will write to memory AND invalidate the cache. > > > > - move the chip errata stuff from irq routine into read/write routines. Made > > it default off since it causes lock ups on my I2C device. I think it causes > > a too short STOP condition. If enabled I2C will behave better than before, but > > may still cause problems if the read/write is interrupted with a signal while > > microcode is enabled. > > > > - set default speed to 60 KHz instead. > > > > - missing/faulty initialization of parameter ram when I2C micro patch is active. > > > > - replaced assingments with mask operations with relevant bits. Example: > > /* Shut down IIC. */ > > i2c->i2c_i2mod = 0; > > i2c->i2c_i2mod &= ~1; > > > > - When reading from I2C device, let the receive BD generate interrupt instead of > > the dummy trasmit. This is important since the TX interrupt will be too early sometimes, before > > the RX BD has closed. There is one case where the RX irq is before the TX irq, if iic_mrblr is set > > to match the number of bytes to read. Therefore must the iic_mrblr be one byte larger than > > the expected number of bytes. > > > > - busy wait for small transfers since it's faster. > > > > - save_flags(flags); cli(); cleanups > > > > - interruptible_sleep_on_timeout() instead of interruptible_sleep_on() so it won't hang forever if an > > irq is lost. > > > > Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-17 21:44 ` Joakim Tjernlund @ 2002-11-18 14:10 ` Tom Rini 2002-11-18 19:04 ` Mark D. Studebaker 0 siblings, 1 reply; 30+ messages in thread From: Tom Rini @ 2002-11-18 14:10 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: Mark D. Studebaker, linuxppc-embedded, sensors On Sun, Nov 17, 2002 at 10:44:40PM +0100, Joakim Tjernlund wrote: > > Tom + Joakim, > > we're doing a release soon over here at sensors/i2c, > > do you want this checked in as-is, with mods, or not at all? > > As-is for me. No problems reported to me. Works for me then. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-18 14:10 ` Tom Rini @ 2002-11-18 19:04 ` Mark D. Studebaker 2002-11-18 19:24 ` Joakim Tjernlund 0 siblings, 1 reply; 30+ messages in thread From: Mark D. Studebaker @ 2002-11-18 19:04 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: Tom Rini, linuxppc-embedded, sensors [-- Attachment #1: Type: text/plain, Size: 529 bytes --] whatever your patch was against didn't match our tree very well. would you please resolve the differences and generate a new patch against our tree? thanks mds Tom Rini wrote: > > On Sun, Nov 17, 2002 at 10:44:40PM +0100, Joakim Tjernlund wrote: > > > > Tom + Joakim, > > > we're doing a release soon over here at sensors/i2c, > > > do you want this checked in as-is, with mods, or not at all? > > > > As-is for me. No problems reported to me. > > Works for me then. > > -- > Tom Rini (TR1265) > http://gate.crashing.org/~trini/ [-- Attachment #2: fail --] [-- Type: text/plain, Size: 537 bytes --] patching file i2c-algo-8xx.c Hunk #1 FAILED at 7. Hunk #2 FAILED at 27. Hunk #3 succeeded at 74 with fuzz 2 (offset 14 lines). Hunk #5 succeeded at 157 (offset 18 lines). Hunk #6 FAILED at 177. Hunk #8 succeeded at 220 (offset 18 lines). Hunk #9 FAILED at 237. Hunk #10 succeeded at 333 (offset 2 lines). Hunk #11 FAILED at 343. Hunk #12 FAILED at 359. Hunk #13 succeeded at 439 (offset 18 lines). Hunk #14 FAILED at 464. Hunk #15 succeeded at 514 (offset 2 lines). 7 out of 15 hunks FAILED -- saving rejects to file i2c-algo-8xx.c.rej ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata 2002-11-18 19:04 ` Mark D. Studebaker @ 2002-11-18 19:24 ` Joakim Tjernlund 2002-11-18 19:31 ` Tom Rini 2002-11-18 19:42 ` Jean Delvare 0 siblings, 2 replies; 30+ messages in thread From: Joakim Tjernlund @ 2002-11-18 19:24 UTC (permalink / raw) To: Mark D. Studebaker; +Cc: Tom Rini, linuxppc-embedded, sensors > whatever your patch was against didn't match our tree very well. would > you please > resolve the differences and generate a new patch against our tree? > thanks > mds Patch was(and still is, I think) against linuxppc_2_4_devel. Don't know your tree, is it not the same as linuxppc? Anyhow, too much time has passed for me to remember all details and I don't have the time to go back and do it all over again. I suggest you take the linuxppc version, patch it and adopt it to your tree. Regards Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-18 19:24 ` Joakim Tjernlund @ 2002-11-18 19:31 ` Tom Rini 2002-11-18 19:42 ` Jean Delvare 1 sibling, 0 replies; 30+ messages in thread From: Tom Rini @ 2002-11-18 19:31 UTC (permalink / raw) To: Joakim Tjernlund; +Cc: Mark D. Studebaker, linuxppc-embedded, sensors On Mon, Nov 18, 2002 at 08:24:32PM +0100, Joakim Tjernlund wrote: > > whatever your patch was against didn't match our tree very well. would > > you please > > resolve the differences and generate a new patch against our tree? > > thanks > > mds > > Patch was(and still is, I think) against linuxppc_2_4_devel. Don't know your tree, is > it not the same as linuxppc? Anyhow, too much time has passed for me > to remember all details and I don't have the time to go back and do it all over again. > I suggest you take the linuxppc version, patch it and adopt it to your tree. I'll go create a proper patch vs the i2c tree later today. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-18 19:24 ` Joakim Tjernlund 2002-11-18 19:31 ` Tom Rini @ 2002-11-18 19:42 ` Jean Delvare 2002-11-18 19:46 ` Tom Rini 1 sibling, 1 reply; 30+ messages in thread From: Jean Delvare @ 2002-11-18 19:42 UTC (permalink / raw) To: joakim.tjernlund; +Cc: mds, trini, linuxppc-embedded, sensors > Patch was(and still is, I think) against linuxppc_2_4_devel. Don't > know your tree, is it not the same as linuxppc? Anyhow, too much time > has passed for me to remember all details and I don't have the time to > go back and do it all over again. I suggest you take the linuxppc > version, patch it and adopt it to your tree. Why the hell are there two different trees? :'( Can't we work all together for a better result? -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: 8xx i2c refers to unspecified chip errata 2002-11-18 19:42 ` Jean Delvare @ 2002-11-18 19:46 ` Tom Rini 0 siblings, 0 replies; 30+ messages in thread From: Tom Rini @ 2002-11-18 19:46 UTC (permalink / raw) To: Jean Delvare; +Cc: joakim.tjernlund, mds, linuxppc-embedded, sensors On Mon, Nov 18, 2002 at 08:42:48PM +0100, Jean Delvare wrote: > > > Patch was(and still is, I think) against linuxppc_2_4_devel. Don't > > know your tree, is it not the same as linuxppc? Anyhow, too much time > > has passed for me to remember all details and I don't have the time to > > go back and do it all over again. I suggest you take the linuxppc > > version, patch it and adopt it to your tree. > > Why the hell are there two different trees? :'( Can't we work all > together for a better result? Because the linuxppc tree doesn't track the whole i2c tree, as that would be quite silly. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: 8xx i2c refers to unspecified chip errata
@ 2002-10-10 17:01 Barker Michael-r43496
0 siblings, 0 replies; 30+ messages in thread
From: Barker Michael-r43496 @ 2002-10-10 17:01 UTC (permalink / raw)
To: linuxppc-embedded
That's good to know - however, I'm just interested in using the CPM. So I will leave my original questions out there, and I may have more in the future. Thanks.
> Dan Wrote
> > Just toggle the bits in software. I never saw an
> application where the I2C
> > controller provided a performance advantage. It's lots of
> software to execute,
> > along with all of the interrupt handling and stuff, so you
> just spend lots of
> > overhead not making any other progress.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 30+ messages in threadend of thread, other threads:[~2002-11-18 19:46 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-10-09 20:14 8xx i2c refers to unspecified chip errata Barker Michael-r43496 2002-10-10 10:35 ` Joakim Tjernlund 2002-10-10 16:18 ` Dan Malek 2002-10-10 16:35 ` Dr. Craig Hollabaugh 2002-10-11 7:28 ` Joakim Tjernlund 2002-10-11 7:50 ` bart 2002-10-11 9:12 ` Joakim Tjernlund 2002-10-11 9:56 ` bart 2002-10-11 12:02 ` Stephan Linke 2002-10-11 12:14 ` bart 2002-10-11 12:31 ` Stephan Linke 2002-10-11 12:46 ` Joakim Tjernlund 2002-10-11 12:44 ` Joakim Tjernlund 2002-10-11 12:55 ` bart 2002-10-11 13:10 ` Joakim Tjernlund 2002-10-15 16:57 ` Tom Rini 2002-10-22 9:15 ` Joakim Tjernlund 2002-10-24 16:10 ` Tom Rini 2002-10-24 18:21 ` Joakim Tjernlund 2002-11-01 11:01 ` Joakim Tjernlund 2002-11-01 19:19 ` Tom Rini 2002-11-17 20:51 ` Mark D. Studebaker 2002-11-17 21:44 ` Joakim Tjernlund 2002-11-18 14:10 ` Tom Rini 2002-11-18 19:04 ` Mark D. Studebaker 2002-11-18 19:24 ` Joakim Tjernlund 2002-11-18 19:31 ` Tom Rini 2002-11-18 19:42 ` Jean Delvare 2002-11-18 19:46 ` Tom Rini -- strict thread matches above, loose matches on Subject: below -- 2002-10-10 17:01 Barker Michael-r43496
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).