From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Rubinstein Subject: Re: Intel ICHx bus driver Date: Mon, 15 Mar 2010 13:12:12 +0200 Message-ID: References: <20100228120817.275ef279@hyperion.delvare> <20100228211949.3297a0ff@hyperion.delvare> <20100312141901.04299a55@hyperion.delvare> <20100312172421.5b4907e6@hyperion.delvare> <20100315110645.1df3e4f0@hyperion.delvare> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20100315110645.1df3e4f0-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jean Delvare Cc: Linux I2C , Ivo Manca List-Id: linux-i2c@vger.kernel.org Perfect :) Btw, you mentioned to disable block buffer for I2C block writes in 2.6.24 but I don't see any change regarding it. Is it in git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git Thanks, =46elix R. On Mon, Mar 15, 2010 at 12:06 PM, Jean Delvare wro= te: > On Mon, 15 Mar 2010 11:43:48 +0200, Felix Rubinstein wrote: >> Hi Jean, >> >> On Fri, Mar 12, 2010 at 6:24 PM, Jean Delvare w= rote: >> > FWIW, testing on my ICH3-M (SMBus block read), I get a delay betwe= en >> > bytes of 460 us. This is a maximum bus speed of 19.6 kHz. Same tes= t on >> > an ICH5 reports a delay of 670 us, which would be 13.5 kHz max. I = have >> > a hard time believing that you got delays below 100 us on your ICH= 9... >> > >> > Also note that, in both cases, the first delay is always much larg= er, >> > as the controller must send the beginning of the transaction up to= the >> > second data byte. The SMBus block read is the worst case scenario,= as >> > it must first send an address byte, the command byte, then the add= ress >> > byte again (direction change), then it reads the block length and >> > finally the first data byte. This is 45 bits on the wire, not coun= ting >> > the start conditions. I get a ~2380 us delay on ICH3-M and ~3420 u= s >> > delay on ICH5. >> > >> > So changing the code the way you suggested isn't trivial. Busy-wai= ting >> > for up to 3500 us for the first transaction isn't very appealing. >> > Busy-waiting for a total of 3500 + 670 * 31 (worst case) =3D 24270= us or >> > almost 25 ms, is hardly pleasant either, latency will suffer, it's >> > almost worse than software bit-banging. Now I have to agree that t= he >> > current implementation ("long" sleeps) isn't good either. Maybe th= e >> > msleep(0) approach would be the least evil... Oh well, at some poi= nt we >> > really want to switch to interrupts. >> >> Thanks for prompt reply :) >> I'll provided more number later on, once I get to it in the lab. >> I have it in my mind to dig into ICH9 data sheet (for the start) to >> add interrupt support. >> Btw, have anyone started it? > > Oh yes, twice. Mark M. Hoffman tried first, with a brand new driver. > Then Ivo Manca (Cc'd) gave it a try, this time modifying the existing > driver. > > The problem with Mark's implementation was that it lacked support for > block transactions, so we couldn't replace the original driver with > his. We did not want to maintain two drivers in parallel, and block > support was never added to the new driver, so Mark's driver did not g= o > anywhere. > > The problem with Ivo's work was that the driver would lock up the bus= in > some cases (I can't remember the details any longer, sorry) and we di= d > not manage to solve this bug. This issue blocked further integration, > and once again the efforts were lost. I can provide Ivo's latest > patches if you want to see what they looked like. With some work, it > should be possible to get them to apply again. I would much prefer > fixing Ivo's patches than starting from scratch again. > > -- > Jean Delvare > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" = in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >