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 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 more
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...
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 fine,
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 still behaves
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
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
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
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 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. And
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 anything
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
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
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's I2C driver.
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
On 12/11/06, Voipio Riku [EMAIL PROTECTED] wrote:
snip
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
> 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
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
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
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 to fetch
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
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
26 matches
Mail list logo
