Komal Shah wrote: > --- Kevin Hilman <[EMAIL PROTECTED]> wrote: > >> I've reverted this patch for a couple reasons: >> >> 1) It broke the ability to handle zero-length transfers, which are >> used >> in the smbus probing code. > > It would be interesting to know that, which device actully didn't > worked with my code.
The audio driver. The probing code used by the aic23 driver explicity depends on the SMBus Quick mode (which you disabled) and when re-enabling that functionality, it still didn't work because the SMBus probe code tests for availability of devices by sending zero-length messages. > As DaVinci I2C controller looks similar to OMAP > I2C controller and so does the code, as it is not good to lie other > code about controller capabilities. Because of that I have removed > extra zero byte transactions handling code and removing SMBUS_QUICK > from it. > > Please refer following discussion on lkml about OMAP I2C driver. > > http://lkml.org/lkml/2006/8/2/138 > > and the latest OMAP I2C driver in Linus mainline tree, as most of other > cosmetic changes are coming from there. OK, I wasn't aware seen this discussion on LKML, and was comparing to the driver in the OMAP git tree which still has the SMBus-quick code and the zero-length byte hack. I think the driver in Linus mainline will not work for probing of chips on OMAP either. I know at least drivers/i2c/chips/tlv320aic23.c driver uses i2c_probe(). That being said, your cleanup is appropriate and definetly in the right direction. I just reverted it for the time being so we can sort out the problems. Keeping the OMAP and DaVinci drivers similiar makes a lot of sense and is the right thing to do, and I appreciate your efforts there. Since the OMAP/DaVinci cannot actually do the SMBus quick, is there a different way to probe for devices? It seems that the i2c_probe code depends on smbus quick functionality. Maybe these layers need to be converted so that some platform_device code can define the addresses instead of using probing. Speaking of smbus and smbus quick, since I'm not very familiar with i2c, do you have any pointers do docs on them? Is it true that the hardware cannot support them? Let's discuss how to change the probing mechanism, and then I'll take your cleanups. They'll have to be remerged though because of some the TI bugfixes that when in yesterday. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
