On Wed, 8 Sep 2010 15:11:36 +0300 Eduardo Valentin <eduardo.valentin@xxxxxxxxx> wrote: > The background here you are probably missing is that the split between > i2c and platform drivers. That has been done because we were thinking also > in the situation where the si4713 i2c driver could be used without the > platform driver. I mean, the i2c code could be re-used for instance by > other v4l2 driver, if that is driving a device which has also si4713. > So, in this sense, the current platform is essentially a wrapper. > And if you split the regulator usage in that way, > we would probably be loosing that. > This is good to know. In that sense it would be good to have some common place for managing the VIO here. > And apart from that, it is also bad from the regfw point of view as well. > I believe the idea is that the driver itself must take care of all needed > regulators. The way you have done, looks like the platform driver needs only > VIO and the i2c needs only VDD. And to my understanding, the i2c needs both > in order to work. So, my suggestion is to move everything to the i2c driver. > Problem of course is that the chip cannot be probed if the VIO is missing so it must be on before the chip is probed. Quite many i2c drivers seems to rely that the VIO is on before probing. Therefore I did here the VIO enable in platform driver as there were this instance on top of i2c driver. I think perfect solution would require some sort of support to i2c core. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
