linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org,
	ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org
Subject: Re: [PATCH V5 Resend 1/2] i2c/adapter: Add bus recovery infrastructure
Date: Thu, 4 Oct 2012 11:47:43 +0200	[thread overview]
Message-ID: <20121004094743.GJ598@pengutronix.de> (raw)
In-Reply-To: <CAKohpon-q9VdP4crEr0KXpDi+AhcOM708PZkJwZzuUH_4p56+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Thu, Oct 04, 2012 at 03:02:26PM +0530, Viresh Kumar wrote:
> On 4 October 2012 14:50, Uwe Kleine-König
> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> 
> >> So, we actually need to do "Low-High" 9 times instead of "High-Low".
> >> So, initializing val to 0 should fix it?
> > I don't think this is enough. If you cut off the last half clock of the
> > first sequence above doing 9 times low-high isn't enough. So you have to
> > do high + 9x low-high to assert 9 full cycles.
> 
> I am not cutting the last half clock. val is the variable which keeps
> track of value to be
> set on the line. I am asking to start from zero.
I meant the sequence that created the stall, not the one intending to
clear it. If you remove the last rising edge from that the SCL line is
initially low.
 
> You mean, we should do a high first and then 9 low-high? But this line was high
> initially.. what difference will it make by making it high again?
> 
> Sorry, i am not a I2C expert, so need some help :)
:(

> >> >> + * @scl_gpio_flags: flag for gpio_request_one of scl_gpio. 0 implies
> >> >> + *   GPIOF_OUT_INIT_LOW.
> >> >> + * @sda_gpio_flags: flag for gpio_request_one of sda_gpio. 0 implies
> >> >> + *   GPIOF_OUT_INIT_LOW.
> >>
> >> > Didn't you want to change this to GPIOF_OUT_INIT_HIGH |
> >> > GPIOF_OPEN_DRAIN? Hmm, I just wonder how to distinguish
> >> > GPIOF_OUT_INIT_LOW from unset. Hmm, maybe assume unset because _LOW is
> >> > wrong?
> >>
> >> Hmmm.... Hmmmm... Hmmm... :)
> >> Two things:
> >> - Why should we default it to GPIOF_OPEN_DRAIN? Open drain would mean,
> >> gpio_set_value() will not write one for it, but would put it in input mode.
> >> I don't think that would be correct, as an generic case.
> > As the i2c-bus is open drain and multi-master capable it's wrong to pull
> > it to 1 because this can result in a short circuit. Even in a
> > single-master scenario (where you can pull SCL in both directions) you
> > must not drive SDA to 1.
> 
> Hmm... Hopefully i understood it well this time.
> - We actually don't need these flags then.
> 
> Always pass:
> - scl_flags: GPIOF_OPEN_DRAIN | GPIOF_OUT_INIT_HIGH
> - sda_flags: GPIOF_IN
> 
> Why would anybody else require something different for any SoC?
IMHO this should work, yes. (At least conceptually, not necessary for
all implementations.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  parent reply	other threads:[~2012-10-04  9:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <viresh.kumar@linaro.org>
2012-09-28 11:26 ` [PATCH V5 1/2] i2c/adapter: Add bus recovery infrastructure Viresh Kumar
     [not found]   ` <d5eaf5302de6a2ba01d1c11abeeed8850be879be.1348831273.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2012-09-28 11:26     ` [PATCH V5 2/2] i2c/designware: Provide i2c bus recovery support Viresh Kumar
2012-10-04  4:29     ` [PATCH V5 Resend 1/2] i2c/adapter: Add bus recovery infrastructure Viresh Kumar
2012-10-04  8:00     ` Uwe Kleine-König
     [not found]       ` <20121004080051.GG598-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-10-04  8:41         ` Viresh Kumar
     [not found]           ` <CAKohpok-4PUz=1OMdJ7-TyWPi+f46k8NgFNUx0Z0La5aN-r5Hw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-10-04  9:20             ` Uwe Kleine-König
     [not found]               ` <20121004092017.GH598-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-10-04  9:32                 ` Viresh Kumar
     [not found]                   ` <CAKohpon-q9VdP4crEr0KXpDi+AhcOM708PZkJwZzuUH_4p56+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-10-04  9:47                     ` Uwe Kleine-König [this message]
     [not found]                       ` <20121004094743.GJ598-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-10-04  9:58                         ` Viresh Kumar
2012-10-04 10:37         ` Viresh Kumar

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=20121004094743.GJ598@pengutronix.de \
    --to=u.kleine-koenig-bicnvbalz9megne8c9+irq@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org \
    --cc=viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@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;
as well as URLs for NNTP newsgroup(s).