On Tue, 14 Jan 2014 19:52:19 +0000, Mark Brown wrote:
I don't disagree with you on common patterns, and I have been an advocate of following these when working in the kernel as it generally makes things simpler and easier. Here I'm not trying to be awkward but am trying to get a simple, flexible, solution which fits best with our devices, whilst still using common kernel frameworks.
That's not what's been coming over.
The drivers follow common patterns. The only thing slightly different is that both the Codec and PMIC are initialised separately, but this reflects the nature of the chip. I don't believe wanting to add a simple solution which fits with that as being awkward or against common methods and am not overly happy you're trying to suggest otherwise, especially when previous kernel submissions I've been involved with have very much followed common kernel practices. I just want the correct solution for our drivers here.
Are you sure that it's not the other way around? It's much more common to have OTP for PMICs... In any case, for the device configured via the register map is there any real scenario where someone might use that feature - devices do have this facility but it's generally never used since by the time you can do register writes to configure the address register I/O is already up and running so it's just making work.
Yes I'm sure, and there are OTP settings for the PMIC as well. For the PMIC address configurability, there isn't really an issue anyway as you need to provide the address for this I2C device at board initialisation in the kernel. The point of note here is that the Codec I2C address is OTP configurable and therefore not fixed.