From: David Brownell <david-b@pacbell.net>
To: Jean Delvare <khali@linux-fr.org>
Cc: Komal Shah <komal_shah802003@yahoo.com>,
akpm@osdl.org, gregkh@suse.de, i2c@lm-sensors.org,
imre.deak@nokia.com, juha.yrjola@solidboot.com,
linux-kernel@vger.kernel.org, r-woodruff2@ti.com,
tony@atomide.com
Subject: Re: [PATCH] OMAP: I2C driver for TI OMAP boards #2
Date: Thu, 3 Aug 2006 07:30:40 -0700 [thread overview]
Message-ID: <200608030730.42458.david-b@pacbell.net> (raw)
In-Reply-To: <20060803111949.91e8e7bc.khali@linux-fr.org>
On Thursday 03 August 2006 2:19 am, Jean Delvare wrote:
> The i2c core provides a mechanism to bypass the probing when you know
> for sure what device is at a given address. For an embedded system, that
> should work.
Unfortunately the mechanisms I'm aware of require either error-prone
kernel command line parameters, or (not error prone, but inelegant)
board-specific logic in the drivers, before driver registration, to
do equivalent stuff.
> > (There's a separate issue about how the I2C stack doesn't just have a
> > mechanism to just declare "this board has these chips, these addresses",
> > so I2C drivers have needless reliance on probing...)
>
> This is being (slowly) addressed by Nathan Lutchansky and Mark M.
> Hoffman. The best solution implies converting the i2c subsystem to the
> device driver model - a non-trivial task.
Glad to hear that fixes are in the works. That's the same conclusion
I reached: that I2C needed those non-trivial changes.
It may help to see how the SPI core solves that problem. Unlike I2C,
SPI actually _can't_ probe (except in rare specialized cases), and when
I did the SPI stuff I was thinking about models that could apply easily
to help I2C avoid probing. (Though not, at this point, code.)
That model of a table of board-specific declarations (with things like
"I2C chip type X at address A, using interrupt I and platform_data P")
should work for I2C too.
- Dave
next prev parent reply other threads:[~2006-08-03 15:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1154066134.13520.267064606@webmail.messagingengine.com>
2006-07-31 14:33 ` [PATCH] OMAP: I2C driver for TI OMAP boards #2 David Brownell
2006-07-31 16:13 ` Jean Delvare
2006-07-31 16:41 ` David Brownell
2006-07-31 19:10 ` Russell King
2006-07-31 23:55 ` David Brownell
2006-08-01 14:33 ` Tony Lindgren
2006-07-31 19:25 ` Jean Delvare
[not found] ` <200607311713.09820.david-b@pacbell.net>
2006-08-02 7:27 ` Jean Delvare
2006-07-31 23:53 ` David Brownell
2006-08-02 15:50 ` Jean Delvare
2006-08-02 19:18 ` David Brownell
2006-08-03 9:19 ` Jean Delvare
2006-08-03 14:30 ` David Brownell [this message]
2006-08-04 8:31 ` Jean Delvare
[not found] <1153980844.20163.266978546@webmail.messagingengine.com>
2006-08-02 15:34 ` 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=200608030730.42458.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@osdl.org \
--cc=gregkh@suse.de \
--cc=i2c@lm-sensors.org \
--cc=imre.deak@nokia.com \
--cc=juha.yrjola@solidboot.com \
--cc=khali@linux-fr.org \
--cc=komal_shah802003@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=r-woodruff2@ti.com \
--cc=tony@atomide.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