public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Nikula <jarkko.nikula@nokia.com>
To: ext Nishanth Menon <menon.nishanth@gmail.com>
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: [PATCH 2/3] ARM: OMAP: Use I2C bus registration helper
Date: Fri, 9 Nov 2007 09:14:52 +0200	[thread overview]
Message-ID: <20071109091452.e4096e71.jarkko.nikula@nokia.com> (raw)
In-Reply-To: <4733044B.9070307@gmail.com>

On Thu, 08 Nov 2007 06:42:51 -0600
"ext Nishanth Menon" <menon.nishanth@gmail.com> wrote:

> Jarkko,
> Jarkko Nikula stated on 11/7/2007 4:54 AM:
> > This patch starts using introduced I2C bus registration helper by
> > cleaning up registration currently done in various places and by
> > doing necessary board file modifications.
> 
> How do I handle Bus segments on (currently) a hypothetical situation
> where i have HS and FS devices on the same i2c bus? There was a long
> discussion
> (http://lists.lm-sensors.org/pipermail/i2c/2007-April/001038.html )
> 
> I am not sure we want to loose that flexibility..
> 
I didn't read the whole thread but I don't see that this framework can
cover that issue any other way than by registering the rate of slowest
known device since this is more device specific problem than bus
registration problem.

I think it is exception if there is a bus with variable speed devices
and where slower devices don't get confused when using higher speed with
other devices.

Probably that short of info can be passed via i2c_board_info? Like
separate device speed and max idle rate. Adapter driver uses then
standard speed when probing and min(device speed, bus rate, min{devices
max idle rate}) while communicating with one. So that maximum bus
communication speed would be limited either by device speed, bus rate or
slowest device idle rate depending which one is lowest.

But anyway. This sounds some short of exception, not standard procedure
we can do automatically?


	Jarkko

  reply	other threads:[~2007-11-09  7:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-07 10:54 [PATCH/RFC 0/3 rev 3] I2C bus registration helper Jarkko Nikula
2007-11-07 10:54 ` [PATCH 1/3] ARM: OMAP: Add helper module for board specific I2C bus registration Jarkko Nikula
2007-11-07 10:54 ` [PATCH 2/3] ARM: OMAP: Use I2C bus registration helper Jarkko Nikula
2007-11-08 12:42   ` Nishanth Menon
2007-11-09  7:14     ` Jarkko Nikula [this message]
2007-11-07 10:54 ` [PATCH 3/3] ARM: OMAP: N800: " Jarkko Nikula
2007-11-15 21:57 ` [PATCH/RFC 0/3 rev 3] " Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2007-11-02 13:46 [PATCH/RFC 0/3] " jarkko.nikula
2007-11-02 13:46 ` [PATCH 2/3] ARM: OMAP: Use " jarkko.nikula
2007-11-02 16:27   ` David Brownell
2007-11-05  8:26     ` Jarkko Nikula
2007-11-05  9:56       ` David Brownell
2007-11-05 13:15 ` Jarkko Nikula

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=20071109091452.e4096e71.jarkko.nikula@nokia.com \
    --to=jarkko.nikula@nokia.com \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=menon.nishanth@gmail.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