From: Andy Walls <awalls@md.metrocast.net>
To: Devin Heitmueller <dheitmueller@kernellabs.com>,
Mark Zimmerman <markzimm@frii.com>
Cc: linux-media@vger.kernel.org
Subject: Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
Date: Sun, 13 Feb 2011 19:16:54 -0500 [thread overview]
Message-ID: <1297642614.19186.38.camel@localhost> (raw)
In-Reply-To: <1297632410.2401.6.camel@localhost>
On Sun, 2011-02-13 at 16:26 -0500, Andy Walls wrote:
> On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote:
> > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote:
> > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman <markzimm@frii.com> wrote:
> > > > Clearly my previous bisection went astray; I think I have a more
> > > > sensible result this time.
> > > >
> > > > qpc$ git bisect good
> > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit
> > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be
> > > > Author: Jean Delvare <khali@linux-fr.org>
> > > > Date: ? Sun Jul 18 16:52:05 2010 -0300
> > > >
> > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions
> > > >
> > > > ? ?Don't just check for nacks on zero-length transactions. Check on
> > > > ? ?other transactions too.
> > >
> > > This could be a combination of the xc5000 doing clock stretching and
> > > the cx23885 i2c master not properly implementing clock stretch. In
> > > the past I've seen i2c masters broken in their handling of clock
> > > stretching where they treat it as a NAK.
> > >
> > > The xc5000 being one of the few devices that actually does i2c clock
> > > stretching often exposes cases where it is improperly implemented in
> > > the i2c master driver (I've had to fix this with several bridges).
> > >
Devin,
I just checked. The CX23885 driver *is* setting up to allow slaves to
stretch the clock.
By analysis, I have confirmed that Jean's sugguested patch that I moved
forward was wrong for the hardware's behavior. When the cx23885 I2C
routines decide to set the I2C_EXTEND flag (and maybe the I2C_NOSTOP
flag), we most certainly should *not* be expecting an ACK from the
particular hardware register. The original commit should certainly be
reverted.
Checking for slave ACK/NAK will need to be done with a little more care;
so for now, I'll settle for ignoring them.
Regards,
Andy
next prev parent reply other threads:[~2011-02-14 0:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101207190753.GA21666@io.frii.com>
2011-01-10 2:14 ` DViCO FusionHDTV7 Dual Express I2C write failed Mark Zimmerman
2011-01-19 15:59 ` VDR User
2011-01-19 16:13 ` Devin Heitmueller
2011-01-19 17:22 ` VDR User
2011-01-19 17:39 ` Mark Zimmerman
2011-01-24 15:49 ` Mark Zimmerman
2011-01-24 15:57 ` Devin Heitmueller
2011-01-25 14:27 ` Mark Zimmerman
2011-01-19 19:01 ` Timothy D. Lenz
2011-01-17 23:12 ` Timothy D. Lenz
2011-02-12 15:29 ` [get-bisect results]: " Mark Zimmerman
2011-02-12 16:27 ` Andy Walls
2011-02-12 16:36 ` Mark Zimmerman
2011-02-12 16:46 ` Andy Walls
2011-02-12 17:03 ` Mark Zimmerman
2011-02-12 19:05 ` Mark Zimmerman
2011-02-12 20:48 ` Andy Walls
2011-02-13 14:47 ` [corrected get-bisect " Mark Zimmerman
2011-02-13 14:52 ` Devin Heitmueller
2011-02-13 20:26 ` Mark Zimmerman
2011-02-13 21:26 ` Andy Walls
2011-02-14 0:16 ` Andy Walls [this message]
2011-02-14 14:29 ` Devin Heitmueller
2011-02-14 0:37 ` Mark Zimmerman
2011-02-14 8:05 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1297642614.19186.38.camel@localhost \
--to=awalls@md.metrocast.net \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
--cc=markzimm@frii.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox