On Mon, 2013-08-05 at 15:42 +0100, Mark Brown wrote:
On Mon, Aug 05, 2013 at 01:25:31PM +0530, Ashish Chavan wrote:
On Mon, 2013-07-29 at 17:01 +0100, Mark Brown wrote:
Well, it's a very unusual hardware design choice to have multiple I2C endpoints in a single physical chip.
I hope to see more of such devices in near future.
There's probably a reason why it's not a common hardware design...
With regmap it should be very straightforward to reuse the same driver for both standalone and non-standalone versions, just a small amount of glue code in the CODEC driver I'd expect. Usually the bus level code is tiny.
The glue code that you are talking about is for the same virtual MFD component that you proposed initially, right? I mean the glue code in CODEC will help it to get attached to the MFD. In this case, in addition to the glue code inside CODEC we will also need additional MFD component. Or I am completely misinterpreting you here?
No, I'm talking about the same thing I was talking about originally.
Thanks for confirming it. From our view point, we still feel that it's not a good design which requires an additional MFD component even to support a stand alone CODEC chip. The way we look at it is, there are so many stand alone CODEC drivers in kernel and most of them are fine without the MFD stub. We wish that our DA9055 CODEC driver should also be treated in the same way. Just placing it in a different hardware package (together with PMIC, in this case) shouldn't necessitate any changes in software. e.g. whether any chip is produced as a BGA component or through hole component, has no effect on it's software.
If you still feel that having additional MFD component is THE correct way to move forward, then I would like to propose another way which seems more logical to us. i.e. changing name of the CODEC driver. We will rename the codec to "da9055c" or something similar to resolve the name collision with PMIC. BTW this is not our preferred way and should be considered as last option.
This message contains information that may be privileged or confidential and is the property of the KPIT Cummins Infosystems Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Cummins Infosystems Ltd. does not accept any liability for virus infected mails.