From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: Moving I2C2 init to plat-omap/devices.c ? Date: Thu, 16 Nov 2006 22:55:19 +0200 Message-ID: <20061116205518.GT21064@atomide.com> References: <200611161219.54874.david-b@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200611161219.54874.david-b@pacbell.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-omap-open-source-bounces@linux.omap.com Errors-To: linux-omap-open-source-bounces@linux.omap.com To: David Brownell Cc: linux-omap-open-source@linux.omap.com List-Id: linux-omap@vger.kernel.org Hi, * David Brownell [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