Re: Moving I2C2 init to plat-omap/devices.c ?

[Tony Lindgren <tony@atomide.com>]

Hi,

* David Brownell <david-b@pacbell.net> [061116 22:21]:
> On Thursday 16 November 2006 6:58 am, Woodruff, Richard wrote:
> 
> > 	Getting any code into the I2C tree might take a bit of effort.
> > Tony floated an interesting idea about creating an embedded I2C using
> > David's frame work.  This might allow faster integration of performance
> > related changes and the like with out fighting with SMB people.
> 
> I pinged the i2c list and got sort of mixed responses about that
> notion of "embedded I2C" (i.e. rewrite) ... so I took a slightly
> different and submitted patches aiming to add more driver model
> compatibility to the current stack.
> 
> That means there'd still be a major functionality gap in the I2C
> stack -- all the calls require a thread context, there are no
> async callbacks -- but at least there's a solution for the setup
> and configuration problems, potentially mergeable in 2.6.20 and
> making the version of i2c-omap.c that's upstream become usable.
> 
> There may still be a need for a separate "embedded" stack though;
> someone who can justify it should do so!
> 
> The patches are:
> 
>  http://lists.lm-sensors.org/pipermail/i2c/2006-November/000458.html
> 	... simple updates, some cleanup plus adding some missing
> 	driver model calls:  shutdown(), and suspend()/resume().
> 	Looks like this will be merged after minor tweaking.
> 
>  http://lists.lm-sensors.org/pipermail/i2c/2006-November/000469.html
> 	... not actually a patch; copied at the end of this message,
> 	this introduces the three interesting patches
> 
>  http://lists.lm-sensors.org/pipermail/i2c/2006-November/000470.html
> 	... first patch mentioned, adds new driver binding model
> 	that fully conforms to the Linux driver model
> 
>  http://lists.lm-sensors.org/pipermail/i2c/2006-November/000468.html
> 	... second patch mentioned, activates that new model
> 
>  http://lists.lm-sensors.org/pipermail/i2c/2006-November/000471.html
> 	... updates OSK support to use it, and tps65010 driver
> 	(but not aic23/ALSA, that's not upstream yet)
> 
> I figure getting those last three patches merged will "take a bit of
> effort", so feel free to weigh in.  In terms of the original post on
> this thread, it sort of assumes the OMAP I2C host would switch over
> to a slightly different registration call, more or less passing the
> platform_device.id ("2" etc) to the I2C layer and saying "use this
> as the bus ID".

Wow, that's great, nice job! That should fix the zero length i2c
probe issue too :)

Tony