On Wed, 3 Jan 2007 20:23:35 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > Works fine, thanks! Unfortunately the i2c-ixp3xx issue has not advanced in
> > the meantime, so we still need the third method.
>
> Right. Thanks for confirming this! Alessandro?
Given that we can not test
On Wednesday 03 January 2007 2:51 pm, Voipio Riku wrote:
>
> > Yes, the patch you sent (switching to "method 3" to work around the
> > evident bug in the i2c-ixp3xx driver) works on the platform I was
> > using too (after unrelated tweaks).
>
> > Here's an updated patch, using "method 3". If it
Hi David,
> Yes, the patch you sent (switching to "method 3" to work around the
> evident bug in the i2c-ixp3xx driver) works on the platform I was
> using too (after unrelated tweaks).
> Here's an updated patch, using "method 3". If it still behaves
> for you, it'd seem ready to merge...
Works
Hi Voipio,
Yes, the patch you sent (switching to "method 3" to work around the
evident bug in the i2c-ixp3xx driver) works on the platform I was
using too (after unrelated tweaks).
Here's an updated patch, using "method 3". If it still behaves
for you, it'd seem ready to merge...
- Dave
=
Executive summary for the new in CC list: Is it possible that i2c-iop3xx
driver in current mainline
Linux is buggy regarding repeated start conditions?
Dan Williams wrote:
According to the latest specification update
(http://www.intel.com/design/iio/specupdt/27351910.pdf) there are no
known iss
On Monday 11 December 2006 2:23 pm, Voipio Riku wrote:
> 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 anythi
On Monday 11 December 2006 3:33 pm, Dan Williams wrote:
>
> According to the latest specification update
> (http://www.intel.com/design/iio/specupdt/27351910.pdf) there are no
> known issues with the i2c.
That's for the 80319 ... Riku said he was using 80219, that
could imply some differences.
On 12/11/06, Voipio Riku <[EMAIL PROTECTED]> wrote:
> 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.
Hi Riku, this is
> 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
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'
> 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 l
On Fri, 8 Dec 2006 18:59:41 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
>
> Note that this reverts part of a previous patch, which seems to have
> included key parts of the initial version of this one. I suspect the
> issue wasn't that "mode 1" didn't work on that board; the original
> code
Update the rtc-rs5c372 driver:
Bugfixes:
- Handle RTCs which are configured to use 12-hour mode.
- Never report bogus/un-initialized times.
- Displaying "raw trim" requires not masking it first!
- Fix the procfs display of crystal and trim data.
Features:
- Handle other RTCs in this f
13 matches
Mail list logo
