mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mark M. Hoffman" <mhoffman@lightlink.com>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [lm-sensors] [PATCH] I2C: i2c_bit_add_bus should initialize SDA and SCL lines
Date: Mon, 12 Jun 2006 08:36:26 -0400	[thread overview]
Message-ID: <20060612123626.GA27429@jupiter.solarsys.private> (raw)
In-Reply-To: <m3lks4k5od.fsf@defiant.localdomain>

Hi Krzysztof:

> "Mark M. Hoffman" <mhoffman@lightlink.com> writes:
> > SCL and SDA must be pulled high by hardware.  If a driver inits to
> > setting them low, that's a bug in the driver.

* Krzysztof Halasa <khc@pm.waw.pl> [2006-06-11 00:27:14 +0200]:
> Thanks for your response.
> 
> The question is rather who inits the lines: a) the hw driver,
> b) the I2C algorithm driver.
> 
> With a) every hw driver has to know how to init them (duplicated
> code but there might be positive side).
> 
> With b) I2C algorithm driver inits the lines and hw driver
> doesn't worry about but it might have some limitations such
> as unknown SCL state.
> 
> I understand the current case is a) - right?

I think it should be, yes.

> The other question is _how_ to init the lines. There are 4 possible
> hardware initial conditions:
> 
>   SCL SDA
> a)  0   0 (outputs zeroed by default)
> b)  0   1 (uncommon but may be left in this state by previous operations)
> c)  1   0 (ditto)
> d)  1   1 (I/O lines configured as input by default)
> 
> The internal state of devices connected to the bus is potentially
> unknown. Some implementations just start with STOP to eliminate
> this problem, I don't know what Linux driver is supposed to do.

If you can read the line state, then yes... I would detect which of
the above four states you're in, and generate a STOP condition for
a, b, and c:

a) setscl(1), setsda(1)
b) setsda(0), setscl(1), setsda(1)
c) setsda(1)

If you can't read the line state... well, that's not actually a proper
I2C bus anyway.  At that point I suggest 'whatever works'.

But even if you need to generate a 'null transfer' (prohibited by spec)
to get reliable operation... that doesn't belong in the algorithm driver.

> (Other implementation I know are rather specialized and thus they
> know their hardware init state, Linux I2C algorithm handles many
> devices with potentially different initial state of hardware lines).
> 
> 
> To summarize questions:
> - is it the hw driver who has to init the bus
> - how to init the bus (depending on init state)

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com


  reply	other threads:[~2006-06-12 12:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-06 16:58 Krzysztof Halasa
2006-06-09 11:05 ` [lm-sensors] " Mark M. Hoffman
2006-06-10 22:27   ` Krzysztof Halasa
2006-06-12 12:36     ` Mark M. Hoffman [this message]
2006-06-12 17:13       ` Krzysztof Halasa

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=20060612123626.GA27429@jupiter.solarsys.private \
    --to=mhoffman@lightlink.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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

all inboxes | Powered by JetHome®