From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Manuel Lauss <mano-nEyxjcs6f3Vin2gBucwGBecsttgLyre6@public.gmane.org>
Cc: i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org,
cd-8pe3aW1LYQvVtiohHAVwjA@public.gmane.org
Subject: Re: [PATCH] i2c: i2c-au1550: properly terminate zero-byte transfers
Date: Fri, 18 Jan 2008 08:33:35 +0100 [thread overview]
Message-ID: <20080118083335.28fd387c@hyperion.delvare> (raw)
In-Reply-To: <20080117163733.GA13110-nEyxjcs6f3Vin2gBucwGBecsttgLyre6@public.gmane.org>
Hi Manuel,
On Thu, 17 Jan 2008 17:37:33 +0100, Manuel Lauss wrote:
> On Thu, Jan 17, 2008 at 04:52:30PM +0100, Jean Delvare wrote:
> > Hi Manuel,
> >
> > This approach looks much nicer than your previous proposal. I like it.
> > Applied, thanks!
>
> Thank you, however there's still the problem with unterminated bus xfers
> after receiving a NAK. I've only seen them with a PCA9539 if one's trying
> to access a non-existant register. However it can't be solved to everyones
> satisfaction I'm afraid...
> (see http://mlau.at/files/i2c-au1550-stopfix-1-behav_2.png )
Indeed. As I understand it, the hardware simply offers no clean
solution to this problem, as you have to ask for the stop condition
before you send an address or data byte. As you can't foresee
transaction failures, you just can't ask for the stop condition before
the failure (or simply nack) happens. Which means that you either don't
send a stop condition at all (what the driver does now) or you send an
extra byte before the stop condition (slightly better but still not
perfect.) Or maybe you have to read the datasheet in details to find
out how to do the right thing, some chips can be very tricky in this
respect.
Anyway, I will take whatever patch you think will improve the situation
on this platform.
--
Jean Delvare
_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c
prev parent reply other threads:[~2008-01-18 7:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-14 8:46 [PATCH] i2c: i2c-au1550: properly terminate zero-byte transfers Manuel Lauss
[not found] ` <20080114084652.GA15392-nEyxjcs6f3Vin2gBucwGBecsttgLyre6@public.gmane.org>
2008-01-17 15:52 ` Jean Delvare
[not found] ` <20080117165230.711e87bf-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-01-17 16:37 ` Manuel Lauss
[not found] ` <20080117163733.GA13110-nEyxjcs6f3Vin2gBucwGBecsttgLyre6@public.gmane.org>
2008-01-18 7:33 ` Jean Delvare [this message]
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=20080118083335.28fd387c@hyperion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=cd-8pe3aW1LYQvVtiohHAVwjA@public.gmane.org \
--cc=i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
--cc=mano-nEyxjcs6f3Vin2gBucwGBecsttgLyre6@public.gmane.org \
/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