Date:	Tue, 12 Dec 2006 00:23:03 +0200 (EET)
From:	"Voipio Riku" <Riku.Voipio@...ial.fi>
To:	"David Brownell" <david-b@...bell.net>
Cc:	rtc-linux@...glegroups.com,
	"Linux Kernel list" <linux-kernel@...r.kernel.org>,
	"Alessandro Zummo" <alessandro.zummo@...ertech.it>,
	dan.j.williams@...el.com, dan.j.williams@...il.com,
	i2c@...sensors.org
Subject: Re: [patch 2.6.19-git] rts-rs5c372 updates:  more chips, alarm,
      12hr mode, etc

> On Sunday 10 December 2006 10:27 pm, Voipio Riku wrote:
>> > Update the rtc-rs5c372 driver:
>> > I suspect the
>> > issue wasn't that "mode 1" didn't work on that board; the original
>> > code to fetch the trim was broken.  If "mode 1" really won't work,
>> > that's almost certainly a bug in that board's I2C driver.

>> It was not related to trim fetching. Yes, it very likely that the boards
>> i2c controller (i2c-iop3xx) is has a bug, but I'm not competent enough
>> to
>> find out what it is actually sending out to the wire.

> I'd expect that would be the controller _driver_ ... although it would
> not surprise me to know there were also (unfixed) silicon bugs to cope
> with, like version-specific differences.  One hopes errata are published
> for the chip you're using, and that they don't lie.

from what I saw, the driver simply passes messages over to the i2c
controller. It even specifically mentiones that it supports repeated start
conditions, as needed for read method #1. Comparing to 80219 manual[1], I
did not spot anything obviously wrong.

> Have you asked around for anyone who may have insights about i2c-iop3xx
> driver bugs?  Maybe the driver maintainers, or arm-linux folk, or on
> the i2c list.

I was told to contact Dan Williams, I didn't get any response.

>> With your patch, the rtc acts like the chip would completely ignore the
>> "address" transfer, and starts reading from the last (default) register
>> anyway. Thus all the regs look shifted by one in the driver.

> That's quite strange.  The docs on the RTC are quite clear about what's
> supposed to happen with what I2C messages.  And I'd expect them to be
> right ... especially since they behaved for me, and the original author
> of that code!  That makes me suspect that your particular I2C controller
> driver must not be issuing the protocol requests it should be, at least
> on your hardware and revision.

Well at least I'm happy that there is now someone more experienced working
on this driver. When I tried to get it working I could not find anyone
with another board to verify if the original and/or my patch works for
them..

>> > +	/* this implements the first (most portable) reading method
>> > +	 * specified in the datasheet.
>> >  	 */

>> Why is this method considered more portable? Howabout making the read
>> method a module parameter?

> Of the three methods, #2 depends on messages that not all I2C masters
> are necessarily going to be able to issue, and #3 assumes that there's
> no other I2C master accessing that chip.

Agreed, I wouldn't consider method #2 either.

> Plus, if I understand things correctly, using mode #3 would break when
> writing

I should not. Writing isn't related to reading methods according the
datasheet[2]. It provides one addressing method for writing, and writing
works fine our Thecus/Allnet hardware.

[1] http://www.intel.com/design/iio/manuals/274017.htm
[2] http://www.ricoh.com/LSI/product_rtc/2wire/5c372/5c372a-e.pdf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists