Hi Mark, See my comments below. Regards, Brian > > - I think i2c-virtual is really the algorithm driver > (i2c-algo-virtual?). > It contains a common algorithm for virtual > drivers. > > - Therefore i2c-virtual_cb is the adapter driver, > specific to the > PCA954x chips (ic2-pca954x?). > The algo/adapter boundary in the 405 driver you > copied may be a little > muddy. > See i2c-algo-bit and its many adapter drivers in > sensors for examples. > It's quite possible I muddied the boundaries here. The reason for keeping the main functionality out of i2c-virtual_cb.c is that this file is where the user-specific and platform-specific code resides. The makefiles in the patch don't actually use i2c-virtual_cb.c - it was included more as an example of usage. In my case, at least, the callbacks are where some of our proprietary code resides and I wanted to keep that isolated. > - I'd rather not add entries to struct > i2c_algorithm, we just went > through that > hell and are finishing a patch to go to Marcelo. > Rather than > xxx_exclusive, > we could use the (essentially unused) > algo_control. i2c-core could > recognize > that a driver is virtual by adding a functionality > entry to identify > that > it is virtual. If you really want it the way it is > we need to put > #ifdefs everywhere > so we can stay compatible, at least for now... > Point well taken. This sounds like a reasonable change. One comment is that the bus exclusivity and multiplexing are two separate things. Even a regular non-multiplexed bus may require 'arbitration' with other blades before being allowed to use it. Likewise some multiplexed busses may not require arbitration. > - If i2c-pca954x also registered as a chip driver > (sensors-style) > (that is, be an i2c client as well) at addresses > 0x70-77 then it will > get called whenever a device is found at that > location, it can do > detection > (if possible -doesn't look like it) and then > register the new busses, > and > everything gets bootstrapped. You'll get called > anytime a bus > is registered. That's better than simply scanning > the > adapters already present at module_init time. > Yes, I originally thought about doing exactly that. In our application due to the variety of different HW platforms it made more sense to register these busses manually based on a priori knowledge of the HW. I'll try to put together a little pcf954x client driver to do the runtime registration of the virtual busses, since that will likely be more useful for the larger audience. > - It's much easier for us if you give us a patch > against CVS, or else > patch > your kernel with our kernel patches first (see > home page) and then > give us a patch > against that kernel. At least for i2c-core. > Understood. Is your CVS based on 2.4 or 2.6? > Brian Kuschak wrote: > > > > Hi Greg, Mark, > > > > As described in a previous email to this list, > this is > > a patch for simplified access to multiplexed i2c > > busses. A documentation file is included, as well > as > > an example (i2c-virtual_cb.c) of how to implement > the > > mux-control callbacks. > > > > Tested on a heavily patched 2.4.19 kernel on > embedded > > PowerPC. However, this patch is against a clean > > kernel.org 2.4.19 tree. I don't have the > bandwidth to > > port this to 2.6.0 right now, but I wanted to make > it > > available in case someone else finds it useful. > > > > Comments/feedback welcome. > > > > Thanks, > > Brian Kuschak > > > > __________________________________ > > Do you Yahoo!? > > Protect your identity with Yahoo! Mail > AddressGuard > > http://antispam.yahoo.com/whatsnewfree > > > > > > Name: > i2c_virtual.2_4_19.patch > > i2c_virtual.2_4_19.patch Type: Plain Text > (text/plain) > > Description: i2c_virtual.2_4_19.patch __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
