* 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 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 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: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: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: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
end 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).